An issue was discovered in 72crm 9.0. There is a SQL Injection vulnerability in View the task calendar.

****Brief of this vulnerability****

72crm v9 has sql injection vulnerability in View the task calendar

****Test Environment****

*   Windows10
*   PHP 5.6.9+Apache/2.4.39

****Affect version****

72crm v9

****Vulnerable Code****

application\\work\\controller\\Task.php line 506

The $param parameter is passed to getDateList

The start\_time parameter and stop\_time parameter are directly spliced ​​into $whereDate, and then executed on line 493. resulting in sql injection vulnerability

****Vulnerability display****

First enter the background

Click as shown,go to the View the task calendar and capture the packet

payload: start\_time=1&stop\_time=1))+or+sleep(2)--+

Sleep successfully for 2 seconds

If debug mode is enabled  
  
payload：start\_time=1&stop\_time=1))+or+updatexml(1,concat(0x7e,database(),0x7e,version()),1)--+  
  
Successfully obtained the database name and version number

CVE-2022-37178: 72crm v9 has sql injection vulnerability · Issue #34 · 72wukong/72crm-9.0-PHP

72crm 9.0 has an Arbitrary file upload vulnerability.

****Brief of this vulnerability****

72crm v9 has Arbitrary file upload vulnerability Where to upload the logo

****Test Environment****

*   Windows10
*   PHP 5.6.9+Apache/2.4.39

****Affect version****

72crm v9

****Vulnerable Code****

application\\admin\\controller\\System.php line 51  
  
After follow-up, it was found that the validate was not set, and the move operation was performed directly, resulting in the ability to upload any file  
  
follow-up move function（set filename）  
line 352:  
  
follow up function  
Generate time-based file names with php as a suffix  
  
then move\_uploaded\_file with this filename （thinkphp\\library\\think\\File.php line 369）  

****Vulnerability display****

First enter the background  
Click as shown,go to the Enterprise management background  
  
click this  
  
Just upload a picture and capture the package, modify the content as follows  
  
Back to enterprise management background  
  
access image address  
  
php code executed successfully  
Notice：Because it is uploaded at the logo, unauthorized users can also access this php code

CVE-2022-37181: 72crm v9 has Arbitrary file upload vulnerability · Issue #35 · 72wukong/72crm-9.0-PHP

A flaw was found in glibc. The realpath() function can mistakenly return an unexpected value, potentially leading to information leakage and disclosure of sensitive data.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[day\] \[month\] \[year\] \[list\]

Date: Mon, 24 Jan 2022 14:05:01 +0000
From: Qualys Security Advisory <qsa@...lys.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: CVE-2021-3998 and CVE-2021-3999 in glibc's realpath() and getcwd()

Hi all,

We discovered two vulnerabilities in the glibc, CVE-2021-3998 in
realpath() and CVE-2021-3999 in getcwd(). Patches are now available at
(many thanks to Siddhesh Poyarekar and Red Hat Product Security):

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ee8d5e33adb284601c00c94687bc907e10aec9bb
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f7a79879c0b2bef0dadd6caaaeeb0d26423e04e5

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=23e0e8f5f1fb5ed150253d986ecccdc90c2dcd5e
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=472e799a5f2102bc0c3206dbd5a801765fceb39c

Below is a short write-up (which is part of a longer advisory that is
mostly unrelated to the glibc and that we will publish at a later date):


========================================================================
CVE-2021-3998: Unexpected return value from glibc's realpath()
========================================================================

While auditing umount and fusermount, we also discovered a vulnerability
in the glibc's realpath() function, which is used internally by various
programs. Normally, when the output buffer "resolved" that is passed to
realpath() is not NULL, then realpath() either returns NULL on failure,
or it returns the output buffer "resolved" on success. Unfortunately,
since commit c6e0b0b ("stdlib: Sync canonicalize with gnulib") from
January 2021, realpath() can mistakenly return a malloc()ated buffer
that is neither NULL nor the output buffer "resolved":

------------------------------------------------------------------------
430 char \*
431 \_\_realpath (const char \*name, char \*resolved)
432 {
...
437   struct scratch\_buffer rname\_buffer;
438   return realpath\_stk (name, resolved, &rname\_buffer);
439 }
------------------------------------------------------------------------
197 static char \*
198 realpath\_stk (const char \*name, char \*resolved,
199               struct scratch\_buffer \*rname\_buf)
200 {
...
399   failed = false;
...
403   if (resolved != NULL && dest - rname <= get\_path\_max ())
404     rname = strcpy (resolved, rname);
...
410   if (failed || rname == resolved)
411     {
412       scratch\_buffer\_free (rname\_buf);
413       return failed ? NULL : resolved;
414     }
415 
416   return scratch\_buffer\_dupfree (rname\_buf, dest - rname);
417 }
------------------------------------------------------------------------

For example, if the input path "name" is "." and if the current working
directory is longer than PATH\_MAX, then:

- at line 399, "failed" is set to false;

- at lines 403-404, "rname" is NOT set to "resolved" and "resolved" is
  left untouched and uninitialized (because "dest - rname" is longer
  than PATH\_MAX);

- the code block at lines 410-414 is skipped (because "failed" is false
  and "rname" is not "resolved");

- at line 416, scratch\_buffer\_dupfree() returns a malloc()ated buffer
  that is NOT the output buffer "resolved".

The consequences of this vulnerability depend on the affected programs;
for example, fusermount (a SUID-root program) can disclose sensitive
information (pointers) when displaying the contents of a stack-based
buffer that is mistakenly left uninitialized by realpath() (we tested
this proof of concept on Ubuntu 21.04):

------------------------------------------------------------------------
$ gcc -o CVE-2021-3998-fusermount CVE-2021-3998-fusermount.c
$ ./CVE-2021-3998-fusermount > CVE-2021-3998-fusermount.output
...

$ hexdump -C CVE-2021-3998-fusermount.output
00000000  2f 75 73 72 2f 62 69 6e  2f 66 75 73 65 72 6d 6f  |/usr/bin/fusermo|
00000010  75 6e 74 3a 20 65 6e 74  72 79 20 66 6f 72 20 f0  |unt: entry for .|
00000020  83 9b 99 ff 7f 20 6e 6f  74 20 66 6f 75 6e 64 20  |..... not found |
00000030  69 6e 20 2f 65 74 63 2f  6d 74 61 62 0a 0a 2f 75  |in /etc/mtab../u|
00000040  73 72 2f 62 69 6e 2f 66  75 73 65 72 6d 6f 75 6e  |sr/bin/fusermoun|
00000050  74 3a 20 65 6e 74 72 79  20 66 6f 72 20 39 ac b7  |t: entry for 9..|
00000060  a5 a2 7f 20 6e 6f 74 20  66 6f 75 6e 64 20 69 6e  |... not found in|
00000070  20 2f 65 74 63 2f 6d 74  61 62 0a 0a              | /etc/mtab..|
------------------------------------------------------------------------


========================================================================
CVE-2021-3999: Off-by-one buffer overflow/underflow in glibc's getcwd()
========================================================================

While studying the vulnerability in realpath(), we also discovered a
vulnerability in the glibc's getcwd() function (which is used internally
by realpath() to resolve relative pathnames) -- an off-by-one buffer
overflow and underflow, but if and only if the "size" of "buf" is
exactly 1:

------------------------------------------------------------------------
 48 \_\_getcwd (char \*buf, size\_t size)
 49 {
 ..
 54   size\_t alloc\_size = size;
 ..
 76     path = buf;
 ..
 80   retval = INLINE\_SYSCALL (getcwd, 2, path, alloc\_size);
...
100   if (retval >= 0 || errno == ENAMETOOLONG)
101     {
...
110       result = \_\_getcwd\_generic (path, size);
------------------------------------------------------------------------
158 \_\_getcwd\_generic (char \*buf, size\_t size)
159 {
...
187   size\_t allocated = size;
...
247     dir = buf;
248 
249   dirp = dir + allocated;
250   \*--dirp = '\\0';
...
262   while (!(thisdev == rootdev && thisino == rootino))
263     {
...
441     }
...
449   if (dirp == &dir\[allocated - 1\])
450     \*--dirp = '/';
...
457   used = dir + allocated - dirp;
458   memmove (dir, dirp, used);
------------------------------------------------------------------------

If, at line 48, the "size" of "buf" is exactly 1:

- and if, at line 80, the kernel's getcwd() syscall fails with the error
  ENAMETOOLONG (because the current working directory is longer than
  PATH\_MAX),

- then, at line 110, a generic implementation of getcwd() is called;

- at line 250, a null byte is written to "dirp", which points exactly to
  "buf" (because "size", and hence "allocated", are exactly 1);

- if the code block at lines 262-441 is skipped entirely (if the current
  working directory corresponds to the "/" directory),

- then, at lines 449-450, a slash is written to "buf-1" (an off-by-one
  buffer underflow, because at line 449 "dirp" was still pointing
  exactly to "buf"),

- and, at lines 457-458, a null byte is written to "buf+1" (an
  off-by-one buffer overflow, because at line 457 "used" is exactly 2).

It may seem impossible to satisfy the condition at line 100 (the current
working directory is longer than PATH\_MAX) and the condition at line 262
(the current working directory corresponds to the "/" directory), but in
reality we can:

- in a child process:

  - create an unprivileged mount namespace;

  - create a directory longer than PATH\_MAX;

  - bind-mount "/" onto this directory;

  - open() this directory and send its file descriptor to the parent
    process (outside the unprivileged mount namespace);

- in the parent process:

  - receive the file descriptor of this directory (which corresponds to
    "/" and is longer than PATH\_MAX) and fchdir() to it;

  - execute a SUID program that calls getcwd() with a buffer of size 1,
    which triggers the off-by-one buffer overflow and underflow.

Apparently, this vulnerability was introduced in February 1995 by the
very first commit in the glibc's git history (28f540f, "initial import")
and could be triggered without an unprivileged mount namespace, by
simply chdir()ing to the "/" directory:

------------------------------------------------------------------------
190 getcwd (buf, size)
...
218     path = buf;
...
226   pathp = path + size;
227   \*--pathp = '\\0';
...
242   while (!(thisdev == rootdev && thisino == rootino))
243     {
...
351     }
352 
353   if (pathp == &path\[size - 1\])
354     \*--pathp = '/';
...
359   memmove (path, pathp, path + size - pathp);
------------------------------------------------------------------------

Although "the size of buf is exactly 1" is a strong requirement,
vulnerable code like the following may exist in the wild:

------------------------------------------------------------------------
#include <unistd.h>
#include <stdio.h>

int main(int argc, char \* argv\[\]) {
    char buf\[4096\];
    int len = snprintf(buf, sizeof(buf), "%s: cwd is ", argv\[0\]);
    if (len <= 0 || (unsigned)len >= sizeof(buf)) return \_\_LINE\_\_;
    if (!getcwd(buf + len, sizeof(buf) - len)) return \_\_LINE\_\_;
    puts(buf);
    return 0;
}
------------------------------------------------------------------------


Thank you very much! We are at your disposal for questions, comments,
and further discussions.

With best regards,

-- 
the Qualys Security Advisory team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2021-3998: security - CVE-2021-3998 and CVE-2021-3999 in glibc's realpath() and getcwd()

Three of the world's leading browsers were measured for phishing and malware protection, with time to block and protection over time as key metrics in test scores.

**AUSTIN, Texas – Aug. 16, 2022** — CyberRatings.org, the nonprofit entity dedicated to providing transparency on cybersecurity product efficacy, has published the results of its 2022 Web Browser Security Test. Google Chrome, Microsoft Edge, and Mozilla Firefox were tested for Phishing Protection and Malware Protection running on Windows 10 and 11.

The Malware tests ran for 24 days with 96 discrete test runs. Phishing tests ran for 20 days with 80 discrete test runs. The reports include measurements of protection against fresh new attacks, consistency of protection over time, and how effective the browser protection was overall.

The ability to warn potential victims that they are about to land on a malicious website or click on a suspicious URL puts web browsers in a unique position to protect the user from an attack. Websites that trick users into downloading malware and phishing campaigns often used for criminal activity have short lifespans, so it is essential that the URL is discovered and added to the reputation system as quickly as possible. A good reputation system must be both accurate and fast to achieve high catch rates.

"Phishing attacks pose a significant risk to individuals and organizations by threatening to compromise or acquire sensitive personal and corporate information," said Vikram Phatak, CEO of CyberRatings.org. "Phishing and Ransomware attacks continue to rise year over year. Consumers should not override the warnings offered by their web browser protection but instead take advantage of the free offering."

*   Malware protection:

*   Microsoft Edge – 97.0%
*   Google Chrome – 88.4%
*   Mozilla Firefox – 84.6%

*   Phishing protection:

*   Microsoft Edge – 91.6%
*   Mozilla Firefox – 90.0%
*   Google Chrome – 89.6%

*   Average time to block a URL from malware:

*   Microsoft Edge 0:56:51
*   Google Chrome 4:46:39
*   Mozilla Firefox 5:18:40

*   Average time to block a phishing URL:

*   Microsoft Edge 0:44:07
*   Mozilla Firefox 1:23:37
*   Google Chrome 2:19:13

The Comparative Test Reports provide detailed results for each product. As a service to the community, CyberRatings.org is providing these reports for free.

**The following browsers were tested:**  

*   Google Chrome: Version 101.0.1210.53 - 102.0.5005.115
*   Microsoft Edge: Version 101.0.1210.47 - 102.0.1254.39
*   Mozilla Firefox: Version 100.0.1 - 101.0.1

**Additional Resources**

*   Follow CyberRatings.org on Twitter
*   Follow CyberRatings.org on LinkedIn

**About CyberRatings.org**

CyberRatings.org is a nonprofit 501(c)6 entity dedicated to quantifying cyber-risk and providing transparency on cybersecurity product efficacy through testing and ratings programs. To become a member, visit www.cyberratings.org

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CyberRatings.org Announces New Web Browser Test Results for 2022

Teleport 9.3.6 is vulnerable to Command injection leading to Remote Code Execution. An attacker can craft a malicious ssh agent installation link by URL encoding a bash escape with carriage return line feed. This url encoded payload can be used in place of a token and sent to a user in a social engineering attack. This is fully unauthenticated attack utilizing the trusted teleport server to deliver the payload.

  

> Read our Blog: https://goteleport.com/blog/

> Read our Documentation: https://goteleport.com/docs/getting-started/

**Table of Contents**

1.  Introduction
2.  Installing and Running
3.  Docker
4.  Building Teleport
5.  Why Did We Build Teleport?
6.  More Information
7.  Support and Contributing
8.  Is Teleport Secure and Production Ready?
9.  Who Built Teleport?

**Introduction**

Teleport is the easiest, most secure way to access all your infrastructure. Teleport is an identity-aware, multi-protocol access proxy which understands SSH, HTTPS, RDP, Kubernetes API, MySQL, MongoDB and PostgreSQL wire protocols.

On the server-side, Teleport is a single binary which enables convenient secure access to behind-NAT resources such as:

*   SSH nodes - SSH works in browsers too!
*   Kubernetes clusters
*   PostgreSQL, MongoDB, CockroachDB and MySQL databases
*   Internal Web apps
*   Windows Hosts
*   Networked servers

Teleport is trivial to set up as a Linux daemon or in a Kubernetes pod. It's rapidly replacing legacy sshd\-based setups at organizations who need:

*   Developer convenience of having instant secure access to everything they need across many environments and cloud providers.
*   Audit log with session recording/replay for multiple protocols
*   Easily manage trust between teams, organizations and data centers.
*   Role-based access control (RBAC) and flexible access workflows (one-time access requests)

In addition to its hallmark features, Teleport is interesting for smaller teams because it facilitates easy adoption of the best infrastructure security practices like:

*   No need to manage shared secrets such as SSH keys: Teleport uses certificate-based access with automatic certificate expiration time for all protocols.
*   Two-factor authentication (2FA) for everything.
*   Collaboratively troubleshoot issues through session sharing.
*   Single sign-on (SSO) for everything via Github Auth, OpenID Connect, or SAML with endpoints like Okta or Active Directory.
*   Infrastructure introspection: Use Teleport via the CLI or Web UI to view the status of every SSH node, database instance, Kubernetes cluster, or internal web app.

Teleport is built upon the high-quality Golang SSH implementation. It is _fully compatible with OpenSSH_, sshd servers, and ssh clients.

Project Links

Description

Teleport Website

The official website of the project.

Documentation

Admin guide, user manual and more.

Demo Video

3-minute video overview of Teleport.

Blog

Our blog where we publish Teleport news.

Forum

Ask us a setup question, post your tutorial, feedback, or idea on our forum.

Slack

Need help with your setup? Ping us in our Slack channel.

Cloud-hosted

We offer Enterprise with a Cloud-hosted option. For teams that require easy and secure access to their computing environments.

**Installing and Running**

| Follow the Installation Guide

Download the latest binary release, unpack the .tar.gz and run sudo ./install. This will copy Teleport binaries into /usr/local/bin.

Then you can run Teleport as a single-node cluster:

In a production environment, Teleport must run as root. For testing or non-production environments, run it as the $USER:

chown $USER /var/lib/teleport

*   In this case, you will not be able to log in as another user.

**Docker**

| Follow the Docker-Compose Getting Started Guide

**Deploy Teleport**

If you wish to deploy Teleport inside a Docker container:

    # This command will pull the Teleport container image for version 8
    docker pull public.ecr.aws/gravitational/teleport:8
    

View latest tags on Amazon ECR Public | gravitational/teleport

**For Local Testing and Development**

Follow the instructions in the docker/README file.

To run a full test suite locally, see the test dependecies list

**Building Teleport**

The teleport repository contains the Teleport daemon binary (written in Go) and a web UI written in Javascript (a git submodule located in the webassets/ directory).

If your intention is to build and deploy for use in a production infrastructure a released tag should be used. The default branch, master, is the current development branch for an upcoming major version. Get the latest release tags listed at https://goteleport.com/download/ and then use that tag in the git clone. For example git clone https://github.com/gravitational/teleport.git -b v9.1.2 gets release v9.1.2.

**Dockerized Build**

It is often easiest to build with Docker, which ensures that all required tooling is available for the build. To execute a dockerized build, ensure that docker is installed and running, and execute:

    make -C build.assets build-binaries
    

**Local Build****Dependencies**

Ensure you have installed correct versions of necessary dependencies:

*   Go version from go.mod
*   If you wish to build the Rust-powered features like Desktop Access, see the Rust and Cargo version in build.assets/Makefile (search for RUST_VERSION)
*   For tsh version > 10.x with FIDO support, you will need libfido and openssl 1.1 installed locally

For an example of Dev Environment setup on a Mac, see these instructions.

**Perform a build**

> **Important**
> 
> *   The Go compiler is somewhat sensitive to the amount of memory: you will need **at least** 1GB of virtual memory to compile Teleport. A 512MB instance without swap will **not** work.
> *   This will build the latest version of Teleport, **regardless** of whether it is stable. If you want to build the latest stable release, run git checkout and git submodule update --recursive to the corresponding tag (for example,
> *   run git checkout v8.0.0) **before** performing a build.

Get the source

git clone https://github.com/gravitational/teleport.git
cd teleport

To perform a build

To build tsh with Apple TouchID support enabled:

> **Important**
> 
> tsh binaries with Touch ID support are only functional using binaries signed with Teleport's Apple Developer ID and notarized by Apple. If you are a Teleport maintainer, ask the team for access.

make build/tsh TOUCHID=yes

To build tsh with libfido:

make build/tsh FIDO2=dynamic

*   On a Mac, with libfido and openssl 1.1 installed via homebrew
    
    export PKG\_CONFIG\_PATH="$(brew --prefix openssl@1.1)/lib/pkgconfig"
    make build/tsh FIDO2=dynamic
    

**Build output and running locally**

If the build succeeds, the installer will place the binaries in the build directory.

Before starting, create default data directories:

sudo mkdir -p -m0700 /var/lib/teleport
sudo chown $USER /var/lib/teleport

**Web UI**

The Teleport Web UI resides in the Gravitational Webapps repo.

**Rebuilding Web UI for development**

To clone this repository and rebuild the Teleport UI package, run the following commands:

git clone git@github.com:gravitational/webapps.git
cd webapps
make build-teleport

Then you can replace Teleport Web UI files with the files from the newly-generated /dist folder.

To enable speedy iterations on the Web UI, you can run a local web-dev server.

You can also tell Teleport to load the Web UI assets from the source directory. To enable this behavior, set the environment variable DEBUG=1 and rebuild with the default target:

# Run Teleport as a single-node cluster in development mode:
DEBUG=1 ./build/teleport start -d

Keep the server running in this mode, and make your UI changes in /dist directory. For instructions about how to update the Web UI, read the webapps README file.

**Updating Web UI assets**

After you commit a change to the webapps repo, you need to update the Web UI assets in the webassets/ git submodule.

Run make update-webassets to update the webassets repo and create a PR for teleport to update its git submodule.

You will need to have the gh utility installed on your system for the script to work. For installation instructions, read the GitHub CLI installation documentation.

**Managing dependencies**

All dependencies are managed using Go modules. Here are the instructions for some common tasks:

**Add a new dependency**

Latest version:

go get github.com/new/dependency

and update the source to use this dependency.

To get a specific version, use go get github.com/new/dependency@version instead.

**Set dependency to a specific version**

go get github.com/new/dependency@version

**Update dependency to the latest version**

go get -u github.com/new/dependency

**Update all dependencies****Debugging dependencies**

Why is a specific package imported?

go mod why $pkgname

Why is a specific module imported?

go mod why -m $modname

Why is a specific version of a module imported?

go mod graph | grep $modname

**Why did We Build Teleport?**

The Teleport creators used to work together at Rackspace. We noticed that most cloud computing users struggle with setting up and configuring infrastructure security because popular tools, while flexible, are complex to understand and expensive to maintain. Additionally, most organizations use multiple infrastructure form factors such as several cloud providers, multiple cloud accounts, servers in colocation, and even smart devices. Some of those devices run on untrusted networks, behind third-party firewalls. This only magnifies complexity and increases operational overhead.

We had a choice, either start a security consulting business or build a solution that's dead-easy to use and understand. A real-time representation of all of your servers in the same room as you, as if they were magically _teleported_. Thus, Teleport was born!

**More Information**

*   Teleport Getting Started
*   Teleport Architecture
*   Reference
*   FAQ

**Support and Contributing**

We offer a few different options for support. First of all, we try to provide clear and comprehensive documentation. The docs are also in Github, so feel free to create a PR or file an issue if you have ideas for improvements. If you still have questions after reviewing our docs, you can also:

*   Join Teleport Discussions to ask questions. Our engineers are available there to help you.
*   If you want to contribute to Teleport or file a bug report/issue, you can create an issue here in Github.
*   If you are interested in Teleport Enterprise or more responsive support during a POC, we can also create a dedicated Slack channel for you during your POC. You can reach out to us through our website to arrange for a POC.

**Is Teleport Secure and Production Ready?**

Teleport is used by leading companies to enable engineers to quickly access any computing resource anywhere. Teleport has completed several security audits from the nationally recognized technology security companies. We make some our audits public, view our latest audit reports.. We are comfortable with the use of Teleport from a security perspective.

You can see the list of companies who use Teleport in production on the Teleport product page.

You can find the latest stable Teleport build on our Releases page.

**Who Built Teleport?**

Teleport was created by Gravitational Inc. We have built Teleport by borrowing from our previous experiences at Rackspace. Learn more about Teleport and our history.

CVE-2022-36633: GitHub - gravitational/teleport: The easiest, most secure way to access infrastructure.

MIMEDefang is a flexible MIME email scanner designed to protect Windows clients from viruses. Includes the ability to do many other kinds of mail processing, such as replacing parts of messages with URLs. It can alter or delete various parts of a MIME message according to a very flexible configuration file. It can also bounce messages with unacceptable attachments. MIMEDefang works with the Sendmail 8.11 and newer "Milter" API, which makes it more flexible and efficient than procmail-based approaches.

MIMEDefang Email Scanner 3.1

Categories: Explained
Categories: Personal
Tags: Mac

Tags:  Parental Controls

Tags:  Screen Time

If you want to know how to secure your Mac so your kids can use it safely, we're here to help.



(Read more...)




The post How to secure a Mac for your kids appeared first on Malwarebytes Labs.

If you want to know how to secure your Mac so your kids can use it safely, I can help.

In 2018 I decided to give my kids an old Apple laptop to share, and I documented the steps I took to secure it. They were still a few years short of their tenth birthdays, and it was their first computer, so I looked into every child safety feature in macOS and dialled everything up to eleven.

It’s now four years later—my kids have changed, the laptop has died and been replaced by another Mac, and we have been through the acid test of several periods of computer-based home schooling, thanks to the pandemic.

As a result I’ve learned a few things about how Apple’s parental controls worked out in practice. In the article I’ll tell you how you can secure your Mac for your kids, and what I found useful about Apple’s safety features.

**Basic security**

Securing a computer for a child is not the same as securing a computer for an adult, although there are significant overlaps and similarities. Malware and malicious websites don’t care if it’s an adult or a child at the screen, so every Mac needs the same basic security precautions in place, no matter who’s using it:

*   **Apply macOS security updates promptly**. All the software on the computer needs to be maintained by installing the latest security updates when they become available. To ensure your Mac is installing macOS updates automatically, choose **Apple menu > System Preferences**, then click **Software Update**, and tick **Automatically keep my Mac up to date**. You can automatically download and install app updates from the App Store by opening App Store and going to **App Store > Preferences** and selecting **Automatic Updates**.
*   **Use security software**. Macs don’t see as much malware as Windows, but it is out there, and you don’t want it on your computer. We strongly recommend that you install a third-party security solution like Malwarebytes Premium for Mac.
*   **Start backing up**. The only backup people ever regret is the one they didn't make. They are your last line of defense against system-altering malware, bad software updates, hardware failure and theft, and simple mistakes. Read Apple’s introduction to Time Machine and get yours working now, before you need it.
*   **Install a password manager**. A password manager is software for creating and remember strong passwords. Good ones also provide a safe way for users to share passwords with other people. Proper password handling is something lots of adults struggle with, so get your kids doing the right thing from day one!

**Security for kids**

In addition to the threats adults face, kids also have to struggle with growing up online. They may have to deal with peer bullying, predatory adults, and harmful content. They may struggle to turn off their devices willingly, and while they may not be as interested as you in invoices from UPS or riches from Nigerian princes, they are naïve and vulnerable to other scams.

For that reason there are a lot of specialist tools for protecting children. On a Mac, they are called Screen Time. But before we look at Screen Time, I want to tell you what I think the most important thing you can do for your kids is, whatever computer they use:

**Set up separate accounts**

The first thing I did on my kids’ laptop was give each child their own separate user account. They each had their own virtual space to arrange as they liked, and it meant I could use different parental control setups for each child if necessary. Most importantly to me, it meant each child would have their own password.

It is much harder to learn good habits if you’ve already been taught bad ones, so I wanted my children to start out expecting they would always have their own account, and that they’d have a password that nobody else knew.

You will need at least two accounts: An admin account for yourself, and a separate account for each child.

Log on to your Mac using your admin account and go to **System Preferences** > **Users & Groups**. On the left side is a list of users. Under your name it should say **Admin**.

Create an account for each child by clicking the padlock, entering your password, and then clicking on the **+** button, choosing a **Standard** account, and filling in the child’s details. When it’s time to enter the password, have the child do it and make a point of looking away.

**My perspective**

Ensuring that both kids had their own account was the best decision I’ve made about securing the Mac. I was concerned that they might find it a drag to log out when they’d finished, or to log the other child out and enter their own password. In fact, they embraced having their own digital space, with their own avatar and wallpaper, and their own mess. Without realising, they have established an important expectation about their digital privacy and security. I hope that when they are older they’ll find it odd if somebody wants to share their account, or expects them to share theirs.

Using separate accounts also allowed me to teach the kids about the importance of keeping passwords secret from the very start. It is very hard to teach a young child how to make a strong password, but it is easy to teach them that a password is a secret.

We made a game of out of picking a password that nobody else was allowed to know, not even me. Over the days and weeks that followed I’d ask “what’s your password” and they delighted in refusing to tell me.

**Screen Time (Parental controls)**

Apple provides parents with controls for restricting what children can and can’t do on their devices.

The functionality was once clearly signposted under the name Parental Controls but is now available through the far-less-obviously named Screen Time, which you’ll find in **System Preferences** > **Screen Time**.

The change from Parental Controls to Screen Time is a shift from a paradigm that imagines adults placing limits on their children, to a paradigm that imagines users placing computer-enforced guardrails _around themselves_ and others. Personally, I find it hard to view this as a step forward, but it acknowledges the reality that it isn’t just kids that can get carried away with screen time.

Screen Time controls can be extended to children via Apple’s Family Sharing, accessible via **Preferences** > **Family Sharing**, and across multiple devices, using iCloud, which brings needed parity with Microsoft’s multi-device view of parental control.

Exhaustive and up-to-date details about how to set up Screen Time are available on Apple’s Use Screen Time on your Mac support page so I will not repeat them here. Suffice to say, the major features offered by Screen Time are:

*   Monitor how much time your child spends on certain apps and websites
*   Schedule downtime, so that certain apps aren’t available at certain times
*   Limit how much time your child can spend on certain apps
*   Restrict what type of content they can see in apps or websites
*   Set limits on who they can communicate with
*   Disallow access to features that might impact privacy, such as the camera

Similar, but less granular features were available via Parental Controls four years ago when I set up my kids’ laptop and I used all of them.

Their accounts would only work at times they were supposed to be awake, and for a maximum of one hour per day.

They were restricted to using a short list of pre-approved websites and apps, and a very short list of people they were allowed to exchange emails with. Whenever there was an option to turn on a content filter, such as restricting access to adult websites or blocking explicit language in music, I turned it on and dialled it up.

**My perspective**

Within a year of setting up the parental controls I removed them all, for two reasons.

Some of the controls simply proved unnecessary. For example, the children already had an established routine around when they could use screens, so it turned out there was simply no need for automatic enforcement of it. And while automatic enforcement didn’t make the kids any safer, it did give us an unwelcome hurdle to clear if we wanted to be flexible and give the children an extra 15 minutes of time.

The other controls I simply found too restrictive. Operating an allow list of websites seems like a great idea until you find yourself adding endless exceptions. Similarly, operating an allow list of apps seems like a great idea until you discover that some apps have dependencies on other apps that aren’t immediately clear. Knowing exactly _what_ you have to add to the allow list in order for something to work was often not as clear as it needed to be.

The straw that finally broke the camel’s back on parental controls for me was school homework tasks.

It is important to understand that I felt I didn’t need the parental controls because we had already created a set of guardrails for our kids and how they use screens. Software restrictions can be useful, but they can only ever be a tool that helps with parenting and not a substitute.

For the next three years I found one other thing helped a great deal.

Because the children didn’t have access to a credit card, and didn’t have the access rights they needed to install software, they had to ask if they wanted to install something or buy something. That provided a bottleneck to prevent a lot of problems. For example, one of my children wanted to buy a game and came to me very excited about it, knowing they could afford it. The child hadn’t realised that the game was a pre-release that asked customers to part with their money and then wait (and hope) for the game to be released. As disappointed as they were, it was a great opportunity to talk about how some things aren’t what they seem.  

All of which is to say Parental Controls didn’t work for us, and our children, in our situation, at a particular age. I would encourage any concerned parent to play with the controls, try them for a reasonable period, and see what works for you. It is unlikely you will hit the bullseye with the first try.

And me? I will be taking another look at Screen Time this summer because one of my children is now racing towards teenage, and is about to get their first phone. This is the biggest change in their access to computing since I gave them the laptop and I will be thinking hard about appropriate rules and guidance, and then looking to see if software can help me.

How to secure a Mac for your kids

A global buffer overflow was discovered in pngcheck function in pngcheck-2.4.0(5 patches applied) via a crafted png file.

**pngcheck** verifies the integrity of PNG, JNG and MNG files (by checking the internal 32-bit CRCs, a.k.a. checksums, and decompressing the image data); it can optionally dump almost all of the chunk-level information in the image in human-readable form. For example, it can be used to print the basic statistics about an image (dimensions, bit depth, etc.); to list the color and transparency info in its palette (assuming it has one); or to extract the embedded text annotations. This is a command-line program with batch capabilities.

Here's some sample output (screen shots, eh?):

    % **pngcheck -cvt ArcTriomphe-iCCP-red-blue-swap.png**
    File: **ArcTriomphe-iCCP-red-blue-swap.png** (5171 bytes)
      chunk IHDR at offset 0x0000c, length 13
        64 x 64 image, 8-bit colormap, non-interlaced
      chunk iCCP at offset 0x00025, length 461
        profile name = Swapped red & blue channel
        compression method = 0 (deflate), compressed profile = 433 bytes
      chunk PLTE at offset 0x001fe, length 759: 253 palette entries
      chunk IDAT at offset 0x00501, length 3616
        zlib: deflated, 32K window, default compression
      chunk tEXt at offset 0x0132d, length 68, keyword: Title
        PNG color-correction test image, swapped red and blue channels
      chunk tEXt at offset 0x0137d, length 143, keyword: Copyright
        Copyright 2005 Greg Roelofs. Licensed under Creative Commons
        AttributionNonCommercial, http://creativecommons.org/licenses/by-nc/2.5/
      chunk tIME at offset 0x01418, length 7: 16 Aug 2005 07:07:07 GMT
      chunk IEND at offset 0x0142b, length 0
    **No errors detected** in ArcTriomphe-iCCP-red-blue-swap.png (8 chunks, -26.2% compression).

    % **pngcheck -c \*.png**
    **OK**: 000000.png (48x48, 1-bit grayscale, non-interlaced, 71.2%).
    **OK**: 000033.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
    **OK**: 000066.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
    **OK**: 000099.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
     \[...\]
    **OK**: ffff66.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
    **OK**: ffff99.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
    **OK**: ffffcc.png (48x48, 1-bit colormap, non-interlaced, 66.0%).
    **OK**: ffffff.png (48x48, 1-bit grayscale, non-interlaced, 70.1%).
    ataylor-bad-text-length.png  illegal (unless recently approved) unknown, public chunk xORk
    **ERROR**: ataylor-bad-text-length.png
    google-island-96x69.png  zlib: inflate error = -3 (data error)
    **ERROR**: google-island-96x69.png

    Errors were detected in 2 of the 218 files tested.
    No errors were detected in 216 of the 218 files tested.

**Vulnerability Warning**

  
pngcheck versions 3.0.2 and earlier have a divide-by-zero bug when zlib-decoding interlaced PNGs with extra data beyond what is required for the declared image dimensions. This bug is fixed in version **3.0.3**, released on 25 April 2021. Again, while all _known_ vulnerabilities are fixed in this version, the code is quite crufty, so it would be safest to assume there are still some problems hidden in there. As always, use at your own risk.

The current release supports all PNG, MNG and JNG chunks, including the newer **sTER** (stereo layout) and **eXIf** (EXIF metadata) chunks. It correctly reports errors in all but two of the images in Chris Nokleberg's brokensuite-20061204. Also included (since version 2.1.0) are two helper utilities:

*   **pngsplit** - break a PNG, MNG or JNG image into constituent chunks (numbered for easy reassembly)
*   **png-fix-IDAT-windowsize** - fix minor zlib-header breakage caused by libpng 1.2.6

The extra utilities are licensed under the GNU General Public License (GPL); pngcheck itself remains under its original, MIT/X11-style license.

**Security and Crash Bugs in Older Versions**

**Vulnerability Warning**

  
pngcheck versions 3.0.1 and earlier have a buffer-overrun bug related to the MNG LOOP chunk (which gets noticed even in PNG files if the \-s option is used). This bug is fixed in version **3.0.2**, released on 31 January 2021. Again, while all _known_ vulnerabilities are fixed in this version, the code is quite crufty, so it would be safest to assume there are still some problems hidden in there. As always, use at your own risk.

**Vulnerability Warning**

  
pngcheck versions 3.0.0 and earlier have a pair of buffer-overrun bugs related to the sPLT and PPLT chunks (the latter is a MNG-only chunk, but it gets noticed even in PNG files if the \-s option is used). Both bugs are fixed in version **3.0.1**, released on 24 January 2021. Again, while all _known_ vulnerabilities are fixed in this version, the code is quite crufty, so it would be safest to assume there are still some problems hidden in there. As always, use at your own risk.

**Vulnerability Warning**

  
pngcheck versions 2.4.0 and earlier have a number of buffer-overrun bugs, most (but not all) of which are related to the -f option ("force continued parsing after major errors"). As such, the option has been removed altogether in version **3.0.0** (which is the reason for the major-version bump), released on 12 December 2020. All _known_ vulnerabilities are fixed in this version, but the code is pretty crufty, so it would be safest to assume there are still some problems hidden in there. As always, use at your own risk.

*   PNG home page
*   MNG home page

 _Last updated 22 August 2021._

Copyright © 2000-2021 Greg Roelofs.

CVE-2020-35511: pngcheck Home Page

VMware Tools (12.0.0, 11.x.y and 10.x.y) contains a local privilege escalation vulnerability. A malicious actor with local non-administrative access to the Guest OS can escalate privileges as a root user in the virtual machine.

Advisory ID: VMSA-2022-0024

CVSSv3 Range: 7.0

Issue Date: 2022-08-23

Updated On: 2022-08-23 (Initial Advisory)

CVE(s): CVE-2022-31676

Synopsis: VMware Tools update addresses a local privilege escalation vulnerability (CVE-2022-31676)

Share this page on social media

Sign up for Security Advisories

****1\. Impacted Products****

*   VMware Tools

****2\. Introduction****

VMware Tools was impacted by a local privilege escalation vulnerability. Updates are available to remediate this vulnerability in affected VMware products.

****3\. Local privilege escalation vulnerability (CVE-2022-31676)****

VMware Tools contains a local privilege escalation vulnerability. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.0.

A malicious actor with local non-administrative access to the Guest OS can escalate privileges as a root user in the virtual machine.

To remediate CVE-2022-31676 apply the patches listed in the 'Fixed Version' column of the 'Response Matrix' found below.

VMware Tools 10.3.25 only applies to the older Linux releases.

Product

Version

Running On

CVE Identifier

CVSSv3

Severity

Fixed Version

Workarounds

Additional Documentation

VMware Tools

12.x.y, 11.x.y

Windows

CVE-2022-31676

7.0

important

12.1.0

None

None

VMware Tools

12.x.y, 11.x.y

Linux

CVE-2022-31676

7.0

important

12.1.0

None

None

VMware Tools

10.x.y

Linux

CVE-2022-31676

7.0

important

10.3.25

None

None

****4\. References****

****5\. Change Log****

**2022-08-23 VMSA-2022-0024  
**Initial security advisory.

****6\. Contact****

CVE-2022-31676: VMSA-2022-0024

IceWarp WebClient DC2 - Update 2 Build 9 (13.0.2.9) was discovered to contain a SQL injection vulnerability via the search parameter at /webmail/server/webmail.php.

\[+\] Title: IceWarp WebClient \[+\] Author: veyselxan \[+\] Vendor Homepage:https://www.icewarp.com/ \[+\] Tested on: Windows 10 \[+\] Versions: 13.0.2.9 \[+\] Fix version: DC2 - Update 2 Build 10 (13.0.2.10) \[+\] Vulnerability Type: SQL injection \[+\] Vulnerable Parameter: "search" \[+\] Vulnerable File: webmail/server/webmail.php \[+\] Cve:CVE-2022-35115 \[+\] Video POC: https://youtu.be/E04ZuqISASQ \[+\] Exploit: INJECTION\_CODE\_POC') AND (SELECT 9056 FROM (SELECT(SLEEP(5)))Ouc0) AND ('bvsb'=bvsb \[+\] Payload: 240 IceWarp WebClient DC2 - Update 2 Build 9 (13.0.2.9) was discovered to contain a SQL injection vulnerability via the search parameter at /webmail/server/webmail.php.

Tag

#windows