A stack overflow vulnerability exists in function read_file in atlibeconf/lib/getfilecontents.c in libeconf 0.5.1 allows attackers to cause a Denial of service or execute arbitrary code.

#ifdef HAVE\_CONFIG\_H # include #endif #include #include #include "libeconf.h" /\* Test case: Open default login.defs from shadow and try out if we can read all entries \*/ int main(int argc, char \*argv\[\]) { econf\_file \*key\_file = NULL; char \*\*keys; size\_t key\_number; char \*val; econf\_err error; if ((error = econf\_readFile (&key\_file, argv\[1\], "= \\t", "#"))) { fprintf (stderr, "ERROR: couldn't read configuration file: %s\\n", econf\_errString(error)); return 1; } if ((error = econf\_getStringValue (key\_file, NULL, "USERGROUPS\_ENAB", &val))) { fprintf (stderr, "Error reading USERGROUPS\_ENAB: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "USERGROUPS\_ENAB returns nothing!\\n"); return 1; } else if (strcmp (val, "yes") != 0) { fprintf (stderr, "USERGROUPS\_ENAB returns wrong value: '%s'\\n", val); return 1; } free (val); if ((error = econf\_getStringValue (key\_file, NULL, "ENV\_SUPATH", &val))) { fprintf (stderr, "Error reading ENV\_SUPATH: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "ENV\_SUPATH returns nothing!\\n"); return 1; } else if (strcmp (val, "PATH=/sbin:/bin:/usr/sbin:/usr/bin") != 0) { fprintf (stderr, "ENV\_SUPATH returns wrong value: '%s'\\n", val); return 1; } free (val); if ((error = econf\_getStringValue (key\_file, "", "UMASK", &val))) { fprintf (stderr, "Error reading UMASK: %s\\n", econf\_errString(error)); return 1; } else if (strlen(val) == 0) { fprintf (stderr, "UMASK returns nothing!\\n"); return 1; } else if (strcmp (val, "022") != 0) { fprintf (stderr, "UMASK returns wrong value: '%s'\\n", val); return 1; } free (val); error = econf\_getKeys(key\_file, NULL, &key\_number, &keys); if (error) { fprintf (stderr, "Error getting all keys: %s\\n", econf\_errString(error)); return 1; } if (key\_number == 0) { fprintf (stderr, "No keys found?\\n"); return 1; } for (size\_t i = 0; i < key\_number; i++) { printf ("%zu: %s\\n", i, keys\[i\]); } econf\_free (keys); econf\_free (key\_file); return 0; }

CVE-2023-30079

A memory leak in ImageMagick 7.0.10-45 and 6.9.11-22 allows remote attackers to perform a denial of service via the "identify -help" command.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-48541: Memory leak in identify -help · Issue #2889 · ImageMagick/ImageMagick

memcached 1.6.7 allows a Denial of Service via multi-packet uploads in UDP.

Expand Up @@ -1183,9 +1183,9 @@ bool resp\_has\_stack(conn \*c) {  
void out\_string(conn \*c, const char \*str) { size\_t len; assert(c != NULL); mc\_resp \*resp \= c\->resp;  
assert(c != NULL); // if response was original filled with something, but we're now writing // out an error or similar, have to reset the object first. // TODO: since this is often redundant with allocation, how many callers Expand Down Expand Up @@ -2604,7 +2604,6 @@ static enum try\_read\_result try\_read\_udp(conn \*c) {  
/\* If this is a multi-packet request, drop it. \*/ if (buf\[4\] != 0 || buf\[5\] != 1) { out\_string(c, "SERVER\_ERROR multi-packet request not supported"); return READ\_NO\_DATA\_RECEIVED; }  
Expand Down

CVE-2022-48571: udp: crash fix when receiving multi-packet uploads · memcached/memcached@6b319c8

An issue was discovered in open-mpi hwloc 2.1.0 allows attackers to cause a denial of service or other unspecified impacts via glibc-cpuset in topology-linux.c.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

ash1852 opened this issue

Aug 31, 2022

· 3 comments

**Comments**

Hi, I found a potential null pointer dereference bug in the project source code of hwloc, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the green text represents some additional information to help understanding when the steps occur and the file path can be seen in the blue framed section.

Although the code shown is for version 2.1.0, this potential bug is still present in the current version

setsize \= CPU\_ALLOC\_SIZE(last+1);

plinux\_set \= CPU\_ALLOC(last+1);

CPU\_ZERO\_S(setsize, plinux\_set);

  
would you can help to check if this bug is true?thank you!

Hello  
Yes, there are likely many corner cases like where we don't check allocation return values. Similar issue in hwloc\_linux\_set\_tid\_cpubind(), hwloc\_linux\_find\_kernel\_nr\_cpus() and hwloc\_linux\_get\_tid\_cpubind(), hwloc\_linux\_set\_thread\_cpubind(), hwloc\_linux\_get\_thread\_cpubind().  
The (bad) rational is that other things will go wrong before this one will trigger a crash. Feel free to send a fix :)

 bgoglin changed the title A potential bug of NPD potential NULL glibc-cpuset dereferences in topology-linux.c

Aug 31, 2022

CVE-2022-47022 was assigned to this issue.

I didn't have any involvement in the assignment, posting here for visibility.

Thanks for the reminder, I forgot about this, I am pushing the fix to master and all stable branches.

bgoglin added a commit that referenced this issue

Aug 24, 2023

CVE-2022-47022: potential NULL glibc-cpuset dereferences in topology-linux.c · Issue #544 · open-mpi/hwloc

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网络安全行业门户

A stack exhaustion issue was discovered in FreeImage before 1.18.0 via the Validate function in PluginRAW.cpp.

> tl;dr:  
> When Load RIFF format files, "size" is read from file. FreeImage seek file pos by "size", and function Validate will call LibRaw::open\_datastream with LibRaw\_freeimage\_datastream, it will call to LibRaw::parse\_riff. If "size" is a negative number(>0x7ffffffff), FreeImage will call LibRaw::parse\_riff function by itself, it eventually causing the stack to be filled.

When the program reads a RIFF format file, it will call to the Validate function of the 'PluginRAW.cpp' file , to validata format.

In Validate function, it will use LibRaw\_freeimage\_datastream to call LibRaw::open\_datastream

static BOOL DLL\_CALLCONV
Validate(FreeImageIO \*io, fi\_handle handle) {           //<---- io is LibRaw\_freeimage\_datastream
......
    // no magic signature : we need to open the file (it will take more time to identify it)
    // do not declare RawProcessor on the stack as it may be huge (300 KB)
    {
        LibRaw \*RawProcessor \= new(std::nothrow) LibRaw;

        if(RawProcessor) {
            BOOL bSuccess \= TRUE;

            // wrap the input datastream
            LibRaw\_freeimage\_datastream datastream(io, handle);

            // open the datastream
            if(RawProcessor->open\_datastream(&datastream) != LIBRAW\_SUCCESS) {     //<---- call LibRaw::open\_datastream
                bSuccess \= FALSE;   // LibRaw : failed to open input stream (unknown format)
            }

            // clean-up internal memory allocations
            RawProcessor-\>recycle();
            delete RawProcessor;

            return bSuccess;
        }
    }

    return FALSE;
}

And will call to LibRaw::parse\_riff function if file start with "RIFF".

FreeImaged.dll!LibRaw::parse\_riff()
FreeImaged.dll!LibRaw::identify()
FreeImaged.dll!LibRaw::open\_datastream(LibRaw\_abstract\_datastream \* stream)
FreeImaged.dll!Validate(FreeImageIO \* io, void \* handle)
FreeImaged.dll!FreeImage\_ValidateFIF(FREE\_IMAGE\_FORMAT fif, FreeImageIO \* io, void \* handle)
FreeImaged.dll!FreeImage\_GetFileTypeFromHandle(FreeImageIO \* io, void \* handle, int size)
FreeImaged.dll!FreeImage\_GetFileType(const char \* filename, int size)

In LibRaw::parse\_riff function, it call itslef by variable "tag". And the "tag" is read from file.

void LibRaw::parse\_riff()
{
  unsigned i, size, end;
  char tag\[4\], date\[64\], month\[64\];
  static const char mon\[12\]\[4\] \= {"Jan", "Feb", "Mar", "Apr", "May", "Jun",
                                  "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"};
  struct tm t;

  order \= 0x4949;
  fread(tag, 4, 1, ifp);
  size \= get4();                                //<---- size read from file
  end \= ftell(ifp) + size;
  if (!memcmp(tag, "RIFF", 4) || !memcmp(tag, "LIST", 4))
  {
    int maxloop \= 1000;
    get4();
    while (ftell(ifp) + 7 < end && !feof(ifp) && maxloop\--)
      parse\_riff();                             //<---- call itself
  }
.......
  }
  else
    fseek(ifp, size, SEEK\_CUR);                 //<---- seek pos by size
}

function get4() just read four bytes.

unsigned LibRaw::get4()
{
  uchar str\[4\] \= {0xff, 0xff, 0xff, 0xff};
  fread(str, 1, 4, ifp);
  return sget4(str);
}

\_\_int64 is file default variable type at LibRaw\_bigfile\_buffered\_datastream in "libraw\_datastream.h"

class DllDef LibRaw\_bigfile\_buffered\_datastream : public LibRaw\_abstract\_datastream
{
public:
......
    virtual INT64 tell();
    virtual INT64 size() { return \_fsize; }
......
protected:
    INT64   readAt(void \*ptr, size\_t size, INT64 off);
......
    INT64 \_fsize;
    INT64 \_fpos; /\* current file position; current buffer start position \*/
......
};

But long is file default variable type at "LibRaw\_freeimage\_datastream" in FreeImageIO.cpp

unsigned DLL\_CALLCONV 
\_ReadProc(void \*buffer, unsigned size, unsigned count, fi\_handle handle) {
    return (unsigned)fread(buffer, size, count, (FILE \*)handle);
}

unsigned DLL\_CALLCONV 
\_WriteProc(void \*buffer, unsigned size, unsigned count, fi\_handle handle) {
    return (unsigned)fwrite(buffer, size, count, (FILE \*)handle);
}

int DLL\_CALLCONV
\_SeekProc(fi\_handle handle, long offset, int origin) {
    return fseek((FILE \*)handle, offset, origin);
}

long DLL\_CALLCONV
\_TellProc(fi\_handle handle) {
    return ftell((FILE \*)handle);
}

So if we let "size" to a negative number, the the file cursor pos could go back to begining of function.  
LibRaw::parse\_riff will call function by itself, it eventually causing the stack to be filled. An attacker can reach a remote denial of service attack by sending a specially constructed file.

windbg:

ModLoad: 00000001\`80000000 00000001\`80a65000   D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Dist\\x64\\FreeImaged.dll
ModLoad: 00007ffa\`f4430000 00007ffa\`f44bd000   C:\\Windows\\SYSTEM32\\MSVCP140.dll
ModLoad: 00007ffb\`5eda0000 00007ffb\`5edac000   C:\\Windows\\SYSTEM32\\VCRUNTIME140\_1.dll
ModLoad: 00007ffb\`7de50000 00007ffb\`7debb000   C:\\Windows\\System32\\WS2\_32.dll
ModLoad: 00007ffb\`69a60000 00007ffb\`69a7b000   C:\\Windows\\SYSTEM32\\VCRUNTIME140.dll
ModLoad: 00007ffb\`39170000 00007ffb\`391a7000   C:\\Windows\\SYSTEM32\\VCOMP140D.DLL
ModLoad: 00007ffb\`7dd20000 00007ffb\`7de4a000   C:\\Windows\\System32\\RPCRT4.dll
(4460.8c84): Break instruction exception \- code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffb\`7ed80770 cc              int     3
0:000\> g
(4460.8c84): Stack overflow \- code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
FreeImaged!\_\_crt\_stdio\_stream::has\_any\_buffer+0x13:
00000001\`8058e103 e808000000      call    FreeImaged!\_\_crt\_stdio\_stream::has\_any\_of (00000001\`8058e110)
0:000\> k
 # Child\-SP          RetAddr               Call Site
00 000000a9\`09a03ff0 00000001\`805a2947     FreeImaged!\_\_crt\_stdio\_stream::has\_any\_buffer+0x13 \[minkernel\\crts\\ucrt\\inc\\corecrt\_internal\_stdio.h @ 221\] 
01 000000a9\`09a04020 00000001\`805a31c0     FreeImaged!\_fread\_nolock\_s+0x2b7 \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 93\] 
02 000000a9\`09a04100 00000001\`805a307d     FreeImaged!fread\_s+0x130 \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 56\] 
03 000000a9\`09a04150 00000001\`8000f564     FreeImaged!fread+0x3d \[minkernel\\crts\\ucrt\\src\\appcrt\\stdio\\fread.cpp @ 240\] 
04 000000a9\`09a04190 00000001\`8005192b     FreeImaged!\_ReadProc+0x34 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\FreeImage\\FreeImageIO.cpp @ 33\] 
05 000000a9\`09a041c0 00000001\`802f1bf1     FreeImaged!LibRaw\_freeimage\_datastream::read+0x3b \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\FreeImage\\PluginRAW.cpp @ 67\] 
06 000000a9\`09a041f0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x81 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 256\] 
07 000000a9\`09a043b0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
08 000000a9\`09a04570 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
09 000000a9\`09a04730 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0a 000000a9\`09a048f0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0b 000000a9\`09a04ab0 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 
0c 000000a9\`09a04c70 00000001\`802f1d11     FreeImaged!LibRaw::parse\_riff+0x1a1 \[D:\\coding\\FreeImage\\freeimage\-svn\-r1889\\FreeImage\\trunk\\Source\\LibRawLite\\src\\metadata\\misc\_parsers.cpp @ 263\] 

TestFile:

data:image/raw;base64,UklGRiAAAAAAAAAAMHg3OQAAAAAwMDAw5P///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\==

CVE-2021-40262: FreeImage / Bugs / #338 A stack buff overflower in function Validate() located in PluginRAW.cpp

Buffer Overflow vulnerability in WritePCXImage function in pcx.c in GraphicsMagick 1.4 allows remote attackers to cause a denial of service via converting of crafted image file to pcx format.

Hi, I found a heap-buffer-overflow in WritePCXImage at pcx.c:1255  
I tested it in GraphicsMagick 1.4  
how to reproduce :

ASAN LOG

\==14178\==ERROR: AddressSanitizer: heap\-buffer\-overflow on address 0x6030000000c0 at pc 0x0000028f29c0 bp 0x7ffec5056070 sp 0x7ffec5056068
WRITE of size 1 at 0x6030000000c0 thread T0
    #0 0x28f29bf in WritePCXImage /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1255:17
    #1 0x8e5c7e in WriteImage /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2245:14
    #2 0x8eac18 in WriteImages /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2404:21
    #3 0x615be6 in ConvertImageCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:6135:11
    #4 0x72e875 in MagickCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:8880:17
    #5 0x810c5c in GMCommandSingle /home/suhwan/project/graphicsmagick\-code/magick/command.c:17412:10
    #6 0x80ba1e in GMCommand /home/suhwan/project/graphicsmagick\-code/magick/command.c:17465:16
    #7 0x7ff6e5aa2b96 in \_\_libc\_start\_main (/lib/x86\_64\-linux\-gnu/libc.so.6+0x21b96)
    #8 0x424239 in \_start (/home/suhwan/project/fuzz\-input\-validate/test/bin/gm+0x424239)

0x6030000000c0 is located 0 bytes to the right of 32\-byte region \[0x6030000000a0,0x6030000000c0)
allocated by thread T0 here:
    #0 0x4cc083 in \_\_interceptor\_malloc /tmp/final/llvm.src/projects/compiler\-rt/lib/asan/asan\_malloc\_linux.cc:146:3
    #1 0x28ddf2c in WritePCXImage /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1172:16
    #2 0x8e5c7e in WriteImage /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2245:14
    #3 0x8eac18 in WriteImages /home/suhwan/project/graphicsmagick\-code/magick/constitute.c:2404:21

SUMMARY: AddressSanitizer: heap\-buffer\-overflow /home/suhwan/project/graphicsmagick\-code/coders/pcx.c:1255:17 in WritePCXImage
Shadow bytes around the buggy address:
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff8000: fa fa fd fd fd fd fa fa 00 00 00 fa fa fa 00 00
\=>0x0c067fff8010: 05 fa fa fa 00 00 00 00\[fa\]fa fa fa fa fa fa fa
  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
\==14178\==ABORTING

GraphicsMagick 1.4 snapshot-20191225 Q8 http://www.GraphicsMagick.org/  
Copyright (C) 2002-2019 GraphicsMagick Group.  
Additional copyrights and licenses apply to this software.  
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:  
Native Thread Safe yes  
Large Files (> 32 bit) yes  
Large Memory (> 32 bit) yes  
BZIP yes  
DPS no  
FlashPix no  
FreeType yes  
Ghostscript (Library) no  
JBIG yes  
JPEG-2000 no  
JPEG yes  
Little CMS yes  
Loadable Modules no  
Solaris mtmalloc no  
OpenMP yes (201107 "3.1")  
PNG yes  
TIFF yes  
TRIO no  
Solaris umem no  
WebP no  
WMF no  
X11 yes  
XML yes  
ZLIB yes

Host type: x86\_64-pc-linux-gnu

CVE-2020-21679: GraphicsMagick / Bugs / #619 heap-buffer-overflow in WritePCXImage

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

A Use After Free vulnerability in svg_dev_text_span_as_paths_defs function in source/fitz/svg-device.c in Artifex Software MuPDF 1.16.0 allows remote attackers to cause a denial of service via opening of a crafted PDF file.

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

Please press **Back** and try again.

CVE-2020-21896: Invalid Bug ID

An infinite recursion in Catalog::findDestInTree can cause denial of service for xpdf 4.02.

**Infinite loop in Catalog::findDestInTree**

Post Reply

*   Print view

Advanced search

3 posts • Page **1** of **1**

shellway

**Posts:** 16

**Joined:** Mon Jun 29, 2020 8:52 pm

**Infinite loop in Catalog::findDestInTree**

*   Quote

Post by **shellway** » Sun Jan 03, 2021 4:43 am

I find an infinite loop in Catalog::findDestInTree. To reproduce it, open poc with xpdf and click the hyperlink in it.

Attachments

poc.txt

(21.8 KiB) Downloaded 207 times

Top

shellway

**Posts:** 16

**Joined:** Mon Jun 29, 2020 8:52 pm

**Re: Infinite loop in Catalog::findDestInTree**

*   Quote

Post by **shellway** » Sun Jan 03, 2021 5:01 am

Sorry. It's not an infinite loop but infinite recursion which crashes xpdf.

Top

derekn

**Posts:** 936

**Joined:** Wed Apr 05, 2017 6:57 pm

**Re: Infinite loop in Catalog::findDestInTree**

*   Quote

Post by **derekn** » Mon Jan 04, 2021 9:01 pm

This is a known issue -- loops in the PDF object structure can cause problems for Xpdf.  
Xpdf 4 catches some of these cases, but not all of them. I'm working on a more robust loop detector for Xpdf 5.

Top

Post Reply

*   Print view

Display: Sort by: Direction:

3 posts • Page **1** of **1**

Return to “Xpdf open source”

Jump to

*   XpdfReader
*   Xpdf open source

Tag

#dos