Multiple stack-based buffer overflows in the expand function in os/pl-glob.c in SWI-Prolog before 6.2.5 and 6.3.x before 6.3.7 allow remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted filename.
Changelog for pl-6.2.5 reads:
FIXED: Possible buffer overrun in patch canonisation code. Pushes pointers on an automatic array without checking for overflow. Can be used for DoS attacks. Will be extremely hard to make it execute arbitrary code.
SECURITY: Possible buffer overflows when expanding file-names with long paths. Affects expandfilename/2. Can lead to crashes (DoS attacks) and possibly execution of arbitrary code if an attacker can control the names of the files searched for, e.g., if expandfilename/2 is used in a directory to which an attacker can upload files for which he can control the name.
These fixes are implemented by upstream commits:
From a9a6fc8a2a9cf3b9154b490a4b1ffaa8be4d723c Mon Sep 17 00:00:00 2001 From: Jan Wielemaker <J.Wielemaker.nl> Date: Sun, 16 Dec 2012 18:13:17 +0100 Subject: [PATCH] FIXED: Possible buffer overrun in patch canonisation code.
Pushes pointers on an automatic array without checking for overflow. Can be used for DoS attacks. Will be extremely hard to make it execute arbitrary code.
From b2c88972e7515ada025e97e7d3ce3e34f81cf33e Mon Sep 17 00:00:00 2001 From: Jan Wielemaker <J.Wielemaker.nl> Date: Sun, 16 Dec 2012 17:29:37 +0100 Subject: [PATCH] SECURITY: Possible buffer overflows when expanding file-names with long paths. Affects expandfilename/2.
Can lead to crashes (DoS attacks) and possibly execution of arbitrary code if an attacker can control the names of the files searched for, e.g., if expandfilename/2 is used in a directory to which an attacker can upload files for which he can control the name.
I believe the vulnerabilities exist in older pl.
GIF image file format readers in various open source projects are based on the GIF decoder implementation written by David Koblas. This implementation contains a bug in the LZW decompressor, causing it to in correctly handle compressed streams that contain code words that were not yet added to the decompression table. LZW decompression has a special case (a KwKwK string) when code word may match the first free entry in the decompression table. The implementation used in this GIF reading code allows code words not only matching, but also exceeding the first free entry.
This problem is identical to a bug found in BSD compress (CVE-2011-2895, bug #727624), but given the unclear relationship between BSD compress and GIF decoder code bases, separate CVE is used here.
Several projects refer to pbmplus as the source form where GIF reading code was taken:
http://www.acme.com/software/pbmplus/
In pbmplus version of the code, the flaw can be found in LWZReadByte():
if (code >= maxcode) { sp++ = firstcode; code = oldcode; }
This allows creating a loop in the decompression table, which leads to an "infinite" loop:
while (code >= clearcode) { sp++ = table[1][code]; if (code == table[0][code]) pmerror("circular table entry BIG ERROR"); code = table[0][code]; }
where:
#define MAXLWZBITS 12 static int table[2][(1<< MAXLWZBITS)]; static int stack[(1<<(MAXLWZBITS))2], sp; sp = stack;
This results in stack[] buffer overflow. If table[][] is located above stack[], stack[] overflow may further modify decoding table and break infinite loop.