Improper access control in the firmware for some Intel(R) Processors may allow an unauthenticated user to potentially enable an escalation of privilege via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**2021.2 IPU - BIOS Advisory**

Intel ID:

INTEL-SA-00527

Advisory Category:

Firmware

Impact of vulnerability:

Escalation of Privilege, Denial of Service, Information Disclosure

Severity rating:

HIGH

Original release:

02/08/2022

Last revised:

02/08/2022

**Summary: **

Potential security vulnerabilities in the BIOS firmware for some Intel® Processors may allow escalation of privilege, denial of service or information disclosure.  Intel is releasing firmware updates to mitigate these potential vulnerabilities.

**Vulnerability Details:**

CVEID: CVE-2021-0103

Description: Insufficient control flow management in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 8.2 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CVEID: CVE-2021-0114

Description: Unchecked return value in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.9 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0115

Description: Buffer overflow in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 7.9 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0116

Description: Out-of-bounds write in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.9 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0117

Description: Pointer issues in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.9 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0118

Description: Out-of-bounds read in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.9 High

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0099

Description: Insufficient control flow management in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.8 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

CVEID: CVE-2021-0156

Description: Improper input validation in the firmware for some Intel(R) Processors may allow an authenticated user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.5 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVEID: CVE-2021-0111

Description: NULL pointer dereference in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 7.2 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0107

Description: Unchecked return value in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 7.2 High

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N

CVEID: CVE-2021-0125

Description: Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:L

CVEID: CVE-2021-0124

Description: Improper access control in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access.

CVSS Base Score: 6.3 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H

CVEID: CVE-2021-0119

Description: Improper initialization in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via physical access.

CVSS Base Score: 5.8 Medium

CVSS Vector: CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L

CVEID: CVE-2021-0092

Description: Improper access control in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable a denial of service via local access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H

CVEID: CVE-2021-0091

Description: Improper access control in the firmware for some Intel(R) Processors may allow an unauthenticated user to potentially enable an escalation of privilege via local access.

CVSS Base Score: 3.2 Low

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N

CVEID: CVE-2021-0093

Description: Incorrect default permissions in the firmware for some Intel(R) Processors may allow a privileged user to potentially enable a denial of service via local access.

CVSS Base Score: 2.4 Low

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L

**Affected Products:**

*   2nd Generation Intel® Xeon® Scalable Processor Family
*   Intel® Xeon® Scalable Processor Family
*   Intel® Xeon® Processor W Family
*   Intel® Xeon® Processor E Family
*   Intel® Xeon® Processor D Family
*   11th Generation Intel® Core™ Processor Family
*   10th Generation Intel® Core™ Processor Family
*   9th Generation Intel® Core™ Processor Family
*   8th Generation Intel® Core™ Processor Family
*   7th Generation Intel® Core™ Processor Family
*   6th Generation Intel® Core™ processor Family
*   Intel® Core™ X-series Processor Family
*   Intel® Atom® Processor C3XXX Family.

**Recommendations:**

Intel recommends that users of listed Intel® Processors update to the latest versions provided by the system manufacturer that addresses these issues.

**Acknowledgements:**

Intel would like to thank Hugo Magalhaes from Oracle for reporting CVE-2021-0107, CVE-2021-0111, CVE-2021-0114, CVE-2021-0115, CVE-2021-0116, CVE-2021-0117, CVE-2021-0118, and CVE-2021-0144.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

02/08/2022

Initial Release

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

CVE-2021-0091: INTEL-SA-00527

A vulnerability was found in systemd. This security flaw can cause a local information leak due to systemd-coredump not respecting the fs.suid_dumpable kernel setting.

*   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: Wed, 21 Dec 2022 12:51:24 +0100
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: systemd-coredump: CVE-2022-4415: local information leak due to
 systemd-coredump not respecting fs.suid\_dumpable kernel setting

Hello list,

this is the publication of a report that was privately shared with the
linux-distros mailing list on 2022-12-09 with a communicated coordinated
release date of 2022-12-20.

I made small changes to the report to reflect recent developments.

This report is about a security issue I found in systemd-coredump.
systemd-coredump is a userspace coredump handler for Linux that is part
of the systemd suite \[1\].

\[1\]: https://github.com/systemd/systemd

The Issue
=========

systemd-coredump sets the sysctl fs.suid\_dumpable by default to 2 via
a sysctl.d drop-in configuration file. For the kernel's builtin coredump
handling this setting means that core dumps for setuid (or otherwise
privileged) processes will be written to disk but will only be
accessible to the root user to avoid sensitive data leaking to
unprivileged user accounts. See also \`man 5 proc\` for the full
documentation of this sysctl.

systemd-coredump in userspace, however, does not respect this kernel
setting in the implementation of its coredump handling. The real user ID
of a dumping process will receive read access to the core dump via an
ACL entry:

    someuser$ cat /proc/sys/kernel/core\_pattern
    |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
    someuser$ cat /cat /proc/sys/fs/suid\_dumpable
    2
    someuser$ /usr/bin/su # run a setuid-root program and keep it running
    Password:
    
    # in another shell trigger a SEGFAULT in the setuid-root program
    someuser$ kill -s SIGSEGV \`pidof su\`
    
    # back in the original shell
    Password: Segmentation fault (core dumped)
    someuser$ cd /var/lib/systemd/coredump
    someuser$ ls -l
    -rw-r-----+ 1 root root 90K Okt 20 11:59 core.su.1000.76f0e40af2a240d98e50b90ab141d974.3529.1666259998000000.zst
    someuser$ getfacl core.su.\*
    # file:
    # core.su.1000.76f0e40af2a240d98e50b90ab141d974.3529.1666259998000000.zst
    # owner: root
    # group: root
    user::rw-
    user:someuser:r--
    group::r--
    mask::r--
    other::---

I have reproduced this on openSUSE Tumbleweed with systemd version 251.
I have been able to reproduce it also on other current Linux
distributions like Arch, Debian, Fedora and SLES.

Patch and Workaround
====================

Attached are the current (two) patches I received from systemd upstream.
Upstream published the fix by now in their GitHub repository \[2\].

A simple workaround without patching systemd-coredump is to revert the
sysctl setting of fs.suid\_dumpable back to 0. In this mode the kernel
will not invoke systemd-coredump for privileged programs. The issue will
thus not be triggered.

\[2\]: https://github.com/systemd/systemd/commit/b7641425659243c09473cd8fb3aef2c0d4a3eb9c

Affected Versions
=================

The vulnerable default of the fs.suid\_dumpable sysctl has been present
since systemd version 246 (introduced via commit 6635f57d3ee). Even
older versions may be affected though, should a system administrator
decide to change this setting to 2.

Upstream states that only systemd starting with version 247 are
affected, I don't know how they come to this different conclusion.

Upstream also states that only builds of systemd with libacl support are
affected. This makes sense since the read access to the core dumps is
granted via ACL entries and there is no fallback to this.

Exploit and Severity
====================

Exploiting this issue is pretty simple at the outset. Regular users are
allowed to send arbitrary signals to privileged processes they create.
Thus the privileged processes can be forced to dump core at arbitrary
points in time and the memory contents of the program will become
accessible via systemd-coredump.

Whether data obtained this way allows for a relevant information leak
depends on the timing, on the one hand, and on the type of program
executed on the other hand. What comes to mind is attempting to obtain
the password hash for the root user account that is stored in
/etc/shadow. Tools like 'su' and 'sudo' will have to process these
password hashes when authenticating the invoking user.

With 'sudo' this will not work, because it actively sets the ulimit for
coredumps to 0. The reason for this is to protect against exactly this
attack scenario \[3\].

With 'su' it works, however. Attached you can find a Python script I
created that shows that it is relatively simple to obtain the root
user's hash digest from /etc/shadow. From here on an attacker can
attempt to crack the hash using a GPU rig, for example. While it is not
a simple local root exploit it can be one if there is a dedicated
attacker.

Other setuid programs (or also programs running only with certain raised
Linux capabilties) could allow for different kinds of information leaks.
Even for 'su' it depends a lot on the PAM stack configuration. Some PAM
modules might read in data from private files in the target user's home
directory, or private configuration files which could leak via
systemd-coredump.

\[3\]: https://github.com/sudo-project/sudo/blob/3040bf54c99ed1baa9e7006be2fed3d5fa71f80e/docs/sudo.man.in#L1260

Timeline
========

2022-10-20: I sent a first report and some questions to
            systemd-security@...hat.com, offering coordinated disclosure.
2022-11-28: Communication did not progress much; I investigated the issue
            further by creating a PoC. Upstream confirmed the issue now and
            acknowledged a higher severity than initially considered.
2022-12-09: The final patches have been shared with us and we agreed to
            the CRD 2022-20-20. I shared the report with the
	    linux-distros mailing list.
2022-12-12: The CVE assignment was communicated by upstream and I also
            shared it with the linux-distros mailing list.
2022-12-20: Upstream published the fix.

Regards

Matthias

-- 
Matthias Gerstner <matthias.gerstner@...e.de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
 
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

**View attachment "**0001-coredump-adjust-whitespace.patch**" of type "**text/plain**" (5417 bytes)**

**View attachment "**0002-coredump-do-not-allow-user-to-access-coredumps-with-.patch**" of type "**text/plain**" (15695 bytes)**

**View attachment "**su\_core\_shadow\_extract.py**" of type "**text/plain**" (6337 bytes)**

**Download attachment "**signature.asc**" of type "**application/pgp-signature**" (834 bytes)**

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-2022-4415: security - systemd-coredump: CVE-2022-4415: local information leak due to systemd-coredump not respecting fs.suid_dumpable kernel setting

The Protect WP Admin WordPress plugin before 3.6.2 does not check for authorisation in the lib/pwa-deactivate.php file, which could allow unauthenticated users to disable the plugin (and therefore the protection offered) via a crafted request

CVE-2021-24906

A lack of capability checks and insufficient nonce check on the AJAX action in the Simple 301 Redirects by BetterLinks WordPress plugin before 2.0.4, made it possible for authenticated users to install arbitrary plugins on vulnerable sites.

CVE-2021-24354

Usermin through 1.850 allows a remote authenticated user to execute OS commands via command injection in a filename for the GPG module.

CVE-2022-35132: Webmin

An arbitrary file write vulnerability in Express-FileUpload v1.3.1 allows attackers to upload multiple files with the same name, causing an overwrite of files in the web application server.

**express-fileupload**

Simple express middleware for uploading files.

![npm](https://camo.githubusercontent.com/6cdf6a999117214ddb2c9efa84c9675877635a5cb119e633c9c5853171c56627/68747470733a2f2f696d672e736869656c64732e696f2f6e706d2f762f657870726573732d66696c6575706c6f61642e737667) ![downloads per month](https://camo.githubusercontent.com/8adf05a4f289c0abf1e39815a6906d33e36b77ebe4e4b4ce93cfb7ef24105e97/687474703a2f2f696d672e736869656c64732e696f2f6e706d2f646d2f657870726573732d66696c6575706c6f61642e737667) ![CircleCI](https://camo.githubusercontent.com/730c1525f788534b709a8da897279e2a0cefc8499da1ba0ea1b649b17ffee569/68747470733a2f2f636972636c6563692e636f6d2f67682f726963686172646769726765732f657870726573732d66696c6575706c6f61642f747265652f6d61737465722e7376673f7374796c653d737667) ![Coverage Status](https://camo.githubusercontent.com/271bc75f097ec338cdfc427c163268f226dfab6792c9f3b923ece75d2fd783c2/68747470733a2f2f696d672e736869656c64732e696f2f636f766572616c6c732f726963686172646769726765732f657870726573732d66696c6575706c6f61642e737667)

**Security Notice**

Please install version 1.1.10+ of this package to avoid a security vulnerability in Node/EJS related to JS prototype pollution. This vulnerability is only applicable if you have the `parseNested` option set to `true` (it is `false` by default).

**Install**

# With NPM
npm i express-fileupload

# With Yarn
yarn add express-fileupload

**Usage**

When you upload a file, the file will be accessible from `req.files`.

Example:

*   You're uploading a file called **car.jpg**
*   Your input's name field is **foo**: `<input name="foo" type="file" />`
*   In your express server request, you can access your uploaded file from `req.files.foo`:

app.post('/upload', function(req, res) {
  console.log(req.files.foo); // the uploaded file object
});

The **req.files.foo** object will contain the following:

*   `req.files.foo.name`: "car.jpg"
*   `req.files.foo.mv`: A function to move the file elsewhere on your server. Can take a callback or return a promise.
*   `req.files.foo.mimetype`: The mimetype of your file
*   `req.files.foo.data`: A buffer representation of your file, returns empty buffer in case useTempFiles option was set to true.
*   `req.files.foo.tempFilePath`: A path to the temporary file in case useTempFiles option was set to true.
*   `req.files.foo.truncated`: A boolean that represents if the file is over the size limit
*   `req.files.foo.size`: Uploaded size in bytes
*   `req.files.foo.md5`: MD5 checksum of the uploaded file

**Notes about breaking changes with MD5 handling:**

*   Before 1.0.0, `md5` is an MD5 checksum of the uploaded file.
*   From 1.0.0 until 1.1.1, `md5` is a function to compute an MD5 hash (Read about it here.).
*   From 1.1.1 onward, `md5` is reverted back to MD5 checksum value and also added full MD5 support in case you are using temporary files.

**Examples**

*   Example Project
*   Basic File Upload
*   Multi-File Upload

**Using Busboy Options**

Pass in Busboy options directly to the express-fileupload middleware. Check out the Busboy documentation here.

app.use(fileUpload({
  limits: { fileSize: 50 \* 1024 \* 1024 },
}));

**Using useTempFile Options**

Use temp files instead of memory for managing the upload process.

// Note that this option available for versions 1.0.0 and newer. 
app.use(fileUpload({
    useTempFiles : true,
    tempFileDir : '/tmp/'
}));

**Using debug option**

You can set `debug` option to `true` to see some logging about upload process. In this case middleware uses `console.log` and adds `Express-file-upload` prefix for outputs.

It will show you whether the request is invalid and also common events triggered during upload. That can be really useful for troubleshooting and _**we recommend attaching debug output to each issue on Github**_.

_**Output example:**_

    Express-file-upload: Temporary file path is /node/express-fileupload/test/temp/tmp-16-1570084843942
    Express-file-upload: New upload started testFile->car.png, bytes:0
    Express-file-upload: Uploading testFile->car.png, bytes:21232...
    Express-file-upload: Uploading testFile->car.png, bytes:86768...
    Express-file-upload: Upload timeout testFile->car.png, bytes:86768
    Express-file-upload: Cleaning up temporary file /node/express-fileupload/test/temp/tmp-16-1570084843942...
    

_**Description:**_

*   `Temporary file path is...` says that `useTempfiles` was set to true and also shows you temp file name and path.
*   `New upload started testFile->car.png` says that new upload started with field `testFile` and file name `car.png`.
*   `Uploading testFile->car.png, bytes:21232...` shows current progress for each new data chunk.
*   `Upload timeout` means that no data came during `uploadTimeout`.
*   `Cleaning up temporary file` Here finaly we see cleaning up of the temporary file because of upload timeout reached.

**Available Options**

Pass in non-Busboy options directly to the middleware. These are express-fileupload specific options.

Option

Acceptable Values

Details

createParentPath

*   `false` **(default)**
*   `true`

Automatically creates the directory path specified in `.mv(filePathName)`

uriDecodeFileNames

*   `false` **(default)**
*   `true`

Applies uri decoding to file names if set true.

safeFileNames

*   `false` **(default)**
*   `true`
*   regex

Strips characters from the upload's filename. You can use custom regex to determine what to strip. If set to `true`, non-alphanumeric characters _except_ dashes and underscores will be stripped. This option is off by default.

**Example #1 (strip slashes from file names):** `app.use(fileUpload({ safeFileNames: /\\/g }))`  
**Example #2:** `app.use(fileUpload({ safeFileNames: true }))`

preserveExtension

*   `false` **(default)**
*   `true`
*   `_Number_`

Preserves filename extension when using `safeFileNames` option. If set to `true`, will default to an extension length of 3. If set to `_Number_`, this will be the max allowable extension length. If an extension is smaller than the extension length, it remains untouched. If the extension is longer, it is shifted.

**Example #1 (true):**  
`app.use(fileUpload({ safeFileNames: true, preserveExtension: true }));`  
_myFileName.ext_ --> _myFileName.ext_

**Example #2 (max extension length 2, extension shifted):**  
`app.use(fileUpload({ safeFileNames: true, preserveExtension: 2 }));`  
_myFileName.ext_ --> _myFileNamee.xt_

abortOnLimit

*   `false` **(default)**
*   `true`

Returns a HTTP 413 when the file is bigger than the size limit if true. Otherwise, it will add a `truncated = true` to the resulting file structure.

responseOnLimit

*   `'File size limit has been reached'` **(default)**
*   `_String_`

Response which will be send to client if file size limit exceeded when abortOnLimit set to true.

limitHandler

*   `false` **(default)**
*   `function(req, res, next)`

User defined limit handler which will be invoked if the file is bigger than configured limits.

useTempFiles

*   `false` **(default)**
*   `true`

By default this module uploads files into RAM. Setting this option to True turns on using temporary files instead of utilising RAM. This avoids memory overflow issues when uploading large files or in case of uploading lots of files at same time.

tempFileDir

*   `String` **(path)**

Path to store temporary files.  
Used along with the `useTempFiles` option. By default this module uses 'tmp' folder in the current working directory.  
You can use trailing slash, but it is not necessary.

parseNested

*   `false` **(default)**
*   `true`

By default, req.body and req.files are flattened like this: `{'name': 'John', 'hobbies[0]': 'Cinema', 'hobbies[1]': 'Bike'}`

When this option is enabled they are parsed in order to be nested like this: `{'name': 'John', 'hobbies': ['Cinema', 'Bike']}`

debug

*   `false` **(default)**
*   `true`

Turn on/off upload process logging. Can be useful for troubleshooting.

uploadTimeout

*   `60000` **(default)**
*   `Integer`

This defines how long to wait for data before aborting. Set to 0 if you want to turn off timeout checks.

**Help Wanted**

Looking for additional maintainers. Please contact `richardgirges [ at ] gmail.com` if you're interested. Pull Requests are welcome!

**Thanks & Credit**

Brian White for his stellar work on the Busboy Package and the connect-busboy Package

CVE-2022-27261: express-fileupload

An issue in LanChain-ai Langchain v.0.0.245 allows a remote attacker to execute arbitrary code via the evaluate function in the numexpr library.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open

corgeman opened this issue

Jul 7, 2023

· 35 comments

**Comments**

The evaluate() function eventually calls eval() on the data provided. eval() is extremely dangerous when supplied with user input and to my knowledge it isn't mentioned that the function does this. I would add a warning in the documentation about this. As a proof-of-concept, the following code should execute the command 'echo verybad' on your computer when ran:

import numexpr
s \= """
(lambda fc=(
    lambda n: \[
        c for c in 
            ().\_\_class\_\_.\_\_bases\_\_\[0\].\_\_subclasses\_\_() 
            if c.\_\_name\_\_ == n
        \]\[0\]
    ):
    fc("function")(
        fc("Popen")("echo verybad",shell=True),{}
    )()
)()
"""
numexpr.evaluate(s)

Yeah developers seem to be using NumExpr more and more as a parser for handling input from a UI. It would be much safer if we could use ast.parse instead. I think adding a warning to the docs is fine, but it would also make sense to me to add an optional sanitizer. We could search the string for various Python keywords that have no business being in an expression, such as:

1.  import
2.  lambda
3.  eval
4.  __ (dunder)
5.  locals
6.  globals

Sanitization could be enabled by default but give the user the means to turn it off.

Alright I implemented a check in 4b2d89c that forbids certain operators used in the expression. Namely: ;, :, [, and __. As far as I can tell this defeats all of the commonly cited attack vectors against eval(). I.e. it bans multiple expressions, lambdas, indexing, and all the dunders. If we want to be very safe, we would want to ban . as a character. However, this is difficult because . is both the reference operator and the decimal operator.

If we want to ban . we could do so if we require it to be followed by a numeral. E.g. 0.1 would pass the check, os.remove would not pass the check. However, this would ban valid Python code such as a * 5. which is a shorthand for casting to double. Perhaps there is someone out their with better regex-foo than myself and can suggest a solution for a regex that bans the Python . operator but doesn't cause issues for decimal points?

Regardless I think this is a good step forward and we're at the point where we should do a new release.

Ok, made some more improvements. I can ban attribute access to everything but .real and .imag, via

_forbidden_re = re.compile('[\;[\:]|__|\.[abcdefghjklmnopqstuvwxyzA-Z_]')

I also strip the string of all whitespace beforehand.

Closing with release of 2.8.5.

Hi @robbmcleod, just wanted to point out that you can still access other attributes because Python translates some utf chars into ascii chars automatically (mainly greek alphabet used in math), thus:

    numexpr.evaluate("(3+1).ᵇit_count()")
    

Results in:

It might be better to whitelist real and imag rather than blacklist chars.

@jan-kubena ok thanks for the heads up. The trouble here is that decimal needs to work, and numbers can appear in variable names, but not at the start. Do you happen to know where the documentation for which character sets are mangled is?

The really proper way to do it would be to back-port the ast parser work I did in for my attempt at making 3.0.

Apparently the pandas group is using dunders as private variables in some of their NumExpr calls.

pandas-dev/pandas#54449

I'm of two minds about this. I could regex against "**\[a-zA-Z0-9\_\]+**" instead of just "\_\_". But for the security conscious, it does feel to me that NumExpr shouldn't be able to access private variables in the locals and globals dictionaries.

Hi folks,

I have a simpler example which also breaks in the new version:

import pandas as pd

name \= "Mass (kg)"
df \= pd.DataFrame({name: \[200, 300, 400\]})
df.query(f"\`{name}\` < 300")

    ValueError: Expression (BACKTICK_QUOTED_STRING_Mass__LPAR_kg_RPAR_) < (300) has forbidden control characters.
    

I understand Mass (kg) is a reasonable column name, so the validation definitely needs more tuning.

Hi folks,  
I'm not sure if it is the same issue here, we are using numexpr for calculations in a pandas dataframe and we are using double underscore in some of our calculations (for instance, a__b) but now it fails in 2.8.5 (working in 2.8.4).  
I have a minimal example without involving pandas:

import numexpr
numexpr.evaluate('a\_\_b / 2', {'a\_\_b': 4})

Or a oneliner:

python -c "import numexpr; print(numexpr.evaluate('a__b / 2', {'a__b': 4}))"

In numexpr==2.8.4 that one works perfectly.  
In numexpr==2.8.5 we have the following:  
ValueError: Expression a__b / 2 has forbidden control characters.

Is it an intentional feature or something that can be workedaround easily (sending some kwarg to ignore the error)?  
We will pin our numexpr requeriments to "<2.8.5" in the meanwhile.

Many thanks!

@nicoddemus and @zorion, just waiting to hear back from Pandas' devs on the original report: pandas-dev/pandas#54449 before I do anything. I've tried in the past to establish some sort of line of communication with them and gotten crickets.

Hi, thanks for your reply.

I think we are having a legit use of dunder but it is not allowed in a breaking change from 2.8.4 to 2.8.5 so we have to fix our version to 2.8.4 (or lower) and this is an ok workaround for now.  
On the other hand, if we had a way to flag "evaluate" that we trust our input we may remove this version restriction. Is it possible to do so?

Many thanks in advance!

> @nicoddemus and @zorion, just waiting to hear back from Pandas' devs on the original report: pandas-dev/pandas#54449 before I do anything. I've tried in the past to establish some sort of line of communication with them and gotten crickets.

Hi, one of the pandas devs here.

I don't maintain the eval code (I don't think anyone still here does anymore), so not really the best person to comment on this.

Is there a way to gate this stricter checking behind an option?  
(For pandas, we have a warning in the docs saying that eval will let users run arbritary code)

Thanks,  
Thomas

@lithomas1 and company,

I see a few approaches here.

1.  We can deprecate the implementation of the __ filter for a immediate release and put it back in for a future release.
2.  We can put in an option to disable the security check. However, I do think it should default to be on.

In order to avoid forcing everyone to do an emergency release, we probably need to do both, assuming the option defaults to sanitize.

> @lithomas1 and company,
> 
> I see a few approaches here.
> 
> 1.  We can deprecate the implementation of the __ filter for a immediate release and put it back in for a future release.
> 2.  We can put in an option to disable the security check. However, I do think it should default to be on.
> 
> In order to avoid forcing everyone to do an emergency release, we probably need to do both, assuming the option defaults to sanitize.

Thanks, this sounds good to me.  
2 is probably good enough for pandas.  
(We are going to be releasing soon anyways in a couple weeks. I think users can be fine pinning numexpr for now).

It would be nice to actually fix pandas, however, I'm not too sure what the future of eval/query will be given its current "zombie"-like state.

There's actually _two_ changes in numexpr 2.8.5 that fail pandas tests - this, and a change to integer overflow behaviour (possibly a result of the negative-powers changes, but I'm not sure yet) pandas-dev/pandas#54546

@rebecca-palmer You can make a new issue if you want, but NumExpr could never cover 2**100 as that's way in excess of 64-bit integers.

@zorion, @nicoddemus, @lithomas1 I made a push in 397cc98 that should hopefully fix these issues, if you could please test?

1.  I improved the blacklisting. It should better match the funny unicode coercion that can be done for the attribute access attack.
2.  It only blocks dunders and not a single double underscore.
3.  You can disable it by calling validate(..., sanitize=False) or equivalently evaluate(..., sanitize=False).

If you have a chance please test and provide me with any feedback you may have.

Hi @robbmcleod,

Thanks for attempting a fix.

My original example now passes, but this one breaks (reduced from the actual code):

import pandas as pd

name \= "II (MM)"
df \= pd.DataFrame({name: \[200, 300, 400\]})
df.query(f"\`{name}\` >= 3.1e-05")

    ValueError: Expression (BACKTICK_QUOTED_STRING_II__LPAR_MM_RPAR_) >= (3.1e-05) has forbidden control characters.
    

The problem in this case seems to be the scientific notation, if I change 3.1e-05 to something that does not format to scientific (say 0.31) then it no longer errors out. If I use the actual number in decimal notation (0.000031) it still fails because it seems internally it formats back to scientific, because it generates the exact same message as above (with 3.1e-05):

import pandas as pd

name \= "II (MM)"
df \= pd.DataFrame({name: \[200, 300, 400\]})
df.query(f"\`{name}\` >= 0.000031")

    ValueError: Expression (BACKTICK_QUOTED_STRING_II__LPAR_MM_RPAR_) >= (3.1e-05) has forbidden control characters.
    

sanitize=False would be great for us, however we call DataFrame.query which does not have that argument yet.

@nicoddemus @robbmcleod I think changing \_attr\_pat to r'.\\b(?!(real|imag|\\d+e?)\\b)' (i.e. adding 'e?') fixes that, but I haven't actually tested it.

Perhaps a more reliable approach would be to use ast.parse, and reject the tree if we find statements, lambdas, dunder import, etc?

@robbmcleod I've added some comments in the commit - do those notify anyone when it's already on the main branch?

It needs to match [eE]?[+-]?. I.e. either 'e' or 'E' can denote scientific notation and then it can be '-' or '+' exponents. It's not a big deal, I just haven't had time to sit down and do it yet. Please be patient.

I definitely don't get notifications on commits.

@nicoddemus I did use ast.parse for the NumExpr-3.0 branch. This is not a trivial fix to backport it. NumExpr 2 has an home-brew AST.

I think that most of the comments are in 397cc98

@robbmcleod Sorry if that looked like a demand to hurry - it was not intended as such, but as a guess that comments that don't notify anyone might _never_ get seen.

Debian now has my version, but it hasn't been through their CI yet.

I'm not sure if I should create a whole new issue for this, but the changes in this commit (which made it into 2.8.5) raise DeprecationWarning: invalid escape sequence '\;' due to the usage \; here, which turns into errors in some CI setups. I left a review comment in 397cc98 to that effect, as well. I can surface this as a bug report of its own if you like.

9b380ae switched to _attr_pat = r'\.\b(?!(real|imag|[eE]?[+-]?\d+)\b)', which probably won't do what you want - I suggest _attr_pat = r'\.\b(?!(real|imag|\d+([eE][+-]?\d+)?)\b)' but I haven't tested that

(The tests don't notice because they use test values without a . (2e-5 not 2.1e-5), which never triggered this issue to begin with. We should maybe change that.)

@rebecca-palmer I don't understand, the point is to disable attribute access. Variable/member names in Python cannot start with a number. So 2.1e-5 should never match the regex because a variable cannot start with 1, for example.

@robbmcleod (?!...) means "does **not** match this", so the items inside the (?!...) (.real, .imag, and numbers with a decimal point) are allowed while other uses of . (other attribute access) are blocked.

kozalosev added a commit to kozalosev/textUtilsBot that referenced this issue

Aug 25, 2023

If no one can think of adding any more tests to this I'll prepare another release?

I'll try and test locally against Pandas as well.

This is out of topic for this issue, but related: is there a link to a discussion to the decision to introduce this check? I ask because using a regex for this seems fragile (as this issue proves), plus the rationale itself seems a bit misguided: if it uses eval behind the covers, I think it would be best to warn users of that fact instead of trying to check that nothing fancy is going on -- because no matter how much the check is well done, it might contain flaws, which will eventually will be passed on to eval, which is a security concern. Perhaps it would make more sense to just let users know that the string is passed on to eval, and the same security concerns apply here.

Ah sorry @rebecca-palmer, seem to have missed it.

I see the suggestion of adding a warning to the docs was given, and then decided to implemented a sanitizer. OK, thanks.

CVE-2023-39631: Warn that evaluate() should not be used on user input · Issue #442 · pydata/numexpr

The Path Sanity Check script of FreeCAD 0.19 is vulnerable to OS command injection, allowing an attacker to execute arbitrary commands via a crafted FCStd document.

![Dismiss Announcement](https://tracker.freecad.org/plugin_file.php?file=Announce/dismiss.png)

****⚠️ ATTENTION!!! ⚠️****

  
**(1)** First post to forum to verify issue  
**(2)** Link said thread to ticket and vice-a-versa  
**(3)** Use the most updated stable or development version  
**(4)** Post your **Help>About FreeCAD>Copy to clipboard** version info  
**(5)** Post a Step-By-Step explanation on how to recreate the issue  
**(6)** Upload an example file to demonstrate problem

**IMPORTANT: POST ONLY v0.20 BUG REPORTS**

*   Anonymous

Date Modified

Username

Field

Change

2021-12-23 15:48

eldstal

New Issue

2021-12-23 15:48

eldstal

Steps to Reproduce Updated

2021-12-23 15:56

eldstal

Tag Attached: security

2021-12-23 15:56

eldstal

Tag Attached: Path

2021-12-23 17:54

eldstal

Product Version

0.19 => 0.20

2021-12-28 22:36

chennes

Project

File formats => Path

2021-12-28 22:36

chennes

Category

Bug => General

2022-01-25 12:58

eldstal

Note Added: 0016287

CVE-2021-45845: 0004810: Security Vulnerability in PathSanity.py

In wlan service, there is a possible out of bounds read due to improper input validation. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07460540; Issue ID: ALPS07460540.

CVE-2023-20818: August 2023

As digital threats against US water, food, health care, and other vital sectors loom large, a new project called UnDisruptable27 aims to help fix cybersecurity weaknesses where other efforts have failed.

An endless parade of data breaches, brutally disruptive ransomware attacks, and crippling IT outages has somehow become the norm around the world. And in spite of escalating impacts to critical infrastructure and daily life, progress has been intermittent and often fleeting. Something's gotta give—and at the BSides Las Vegas security conference this week, a longtime critical-infrastructure security researcher is launching a project to communicate with utility operators, municipalities, and regular people in creative ways about both urgency and optimism around protecting critical infrastructure now.

Dubbed UnDisruptable27, the project will start as a pilot with a $700,000 grant for the first year through Craig Newmark Philanthropies' Cyber Civil Defense coalition. Led by Josh Corman, who was chief strategist for the US Cybersecurity and Infrastructure Security Agency's Covid Task Force, in collaboration with the Institute for Security and Technology (IST), the project will focus on the critical interdependence of water, food, emergency medical care, and power as the backbone of human safety. Corman says that the key goal is to foster new discourse about these challenges inspired by the disaster management tenets “inform, influence, inspire.” In other words, people need to understand the risks and feel empowered that they can take action.

“We are overdependent on undependable things. No one should feel comfortable with the potential for harm here with our current state of defense,” Corman told WIRED ahead of the announcement. “Our dependence on connected tech has grown faster than our ability to secure it. People have been doing good things, but public policy takes time, and I think this year we need to cross certain thresholds on the sense of urgency.”

One of Corman's main motivations to launch the effort as quickly as possible came from comments made during a January congressional hearing about the cybersecurity threat China poses to the US. In the hearing, then Cyber Command head and NSA director Paul Nakasone, Cybersecurity and Infrastructure Security Agency director Jen Easterly, FBI director Christopher Wray, and head of the Office of the National Cyber Director Harry Coker Jr. testified about pressing threats to US critical infrastructure, including specific campaigns the Chinese hacking group known as Volt Typhoon has been conducting to pre-position itself in US water infrastructure. The goal of this targeting is apparently to create leverage and a credible threat against the US as part of a Chinese plan to invade Taiwan, potentially in 2027.

“The budgets that emerge from discussions underway now will dictate what kind of resources we have ready in 2027, a year that, as this committee knows all too well, the CCP has circled on its calendar,” Wray told the US House of Representatives committee in January. “And that year will be on us before you know it. As I've described, the PRC is already today putting their pieces in place. I do not want those watching today to think we can't protect ourselves, but I do want the American people to know that we cannot afford to sleep on this danger.”

Having worked on embedded device security and critical infrastructure defense for years, including through the decade-old grassroots computer security and human safety initiative he founded known as I Am the Cavalry, Corman says that it felt significant that some of the nation's top intelligence officials were warning Congress of such specific threats to US infrastructure in an unclassified setting.

“It’s not just that the water goes out, it’s that when the sole wastewater facility in your community is down really bad things start to happen. For example, no water means no hospital,” he says. “I really encountered a lot of this during my leadership of the Covid Task Force. There is such interdependence across the basic functions of society.”

UnDisruptable27 will focus on interacting with communities who aren't reached by Washington, DC-based policy discussions or Information Sharing and Analysis Centers (ISACs), which are meant to represent each infrastructure sector of the US. The project aims to communicate directly with people who actually work on the ground in US critical infrastructure, and grapple together with the reality that cybersecurity-related disasters could impact their daily work.

“There’s a data breach, you get whatever services like identity protection for some period of time, and life carries on, and people think that there’s no long-term impact," says Megan Stifel, IST's chief strategy officer. “There’s this expectation that it’s fine, things will just continue. So we’re very interested in getting after this issue and thinking about how do we tackle critical infrastructure security with perhaps a new approach.”

Corman notes that even though cybersecurity incidents have become a well-known fact of life, business owners and infrastructure operators are often shaken and caught off guard when a cybersecurity incident actually affects them. Meanwhile, when government entities try to impose cybersecurity standards or become a partner on defense initiatives, communities often balk at the intrusion and perceived overreach. Last year, for example, the US Environmental Protection Agency was forced to rescind new cybersecurity guidelines for water systems after water companies and Republicans in Congress filed a lawsuit over the initiative.

“Time and time again, trade associations or lobbyists or owners and operators have an allergic reaction to oversight and say, ‘We prefer voluntary, we’re doing fine on our own,’” Corman says. “And they really are trying to do the right thing. But then also time and time again, people are just shocked that disruption could happen and feel very blindsided. So you can only conclude that the people who feel the pain of our failures are not included in the conversation. They deserve to understand the risks inherent in this level of connectivity. We’ve tried a lot of things, but we have not tried just leveling with people.”

UnDisruptable27 is launching this week for visibility among attendees at BSides as well as the other conferences, Black Hat and Defcon, that will run through Sunday in Las Vegas. Corman says that the goal is to combine the hacker mentality and, essentially, a call for volunteers with plans to work with creative collaborators on producing engaging content to fuel discourse and understanding. Information campaigns using memes and social media posts or moonshots like narrative podcasts and even reality TV are all on the table.

“We must prioritize the security, safety, and resilience of critical infrastructure—including water, health care facilities, and utilities," Craig Newmark, the Craigslist founder whose philanthropy is funding UnDisruptable27, told WIRED. "The urgency of this issue requires affecting human behavior through storytelling.”

Search

lenovo warranty check/lookup | check warranty status | lenovo support us