Bug 446902 - (CVE-2008-2363) CVE-2008-2363 pan: heap overflow caused by large *.nzb files
CVE-2008-2363 pan: heap overflow caused by large *.nzb files
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Alexander Dalloz
Fedora Extras Quality Assurance
:
Depends On: 449333 449334 449335
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-16 12:01 EDT by Pavel Polischouk
Modified: 2012-05-24 17:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-24 17:37:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Tasks.nzb causing corrupted double-linked list abort from glibc (40.46 KB, text/plain)
2008-05-21 14:17 EDT, Pavel Polischouk
no flags Details
Glibc-generated stack trace from abort (4.45 KB, text/plain)
2008-05-21 14:21 EDT, Pavel Polischouk
no flags Details
Tasks.nzb causing pan to segfault (19.61 KB, text/plain)
2008-05-21 14:24 EDT, Pavel Polischouk
no flags Details
Stack trace from segfault (1.37 KB, text/plain)
2008-05-21 14:25 EDT, Pavel Polischouk
no flags Details
Tasks.nzb causing assertion in pan. (26.86 KB, text/plain)
2008-05-21 14:33 EDT, Pavel Polischouk
no flags Details
Stack trace from assertion (1.23 KB, text/plain)
2008-05-21 14:33 EDT, Pavel Polischouk
no flags Details
Fix the assertion in PAN due to sorting of an array containing redundant elements (2.69 KB, patch)
2008-05-27 22:53 EDT, Pavel Polischouk
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 535413 None None None Never

  None (edit)
Description Pavel Polischouk 2008-05-16 12:01:51 EDT
Description of problem:


Version-Release number of selected component (if applicable):
pan-0.132-2.fc8.x86_64

How reproducible:
Always

Steps to Reproduce:
  Start pan from the command line
  
Actual results:

pan: parts.cc:244: void pan::Parts::set_parts(const pan::PartBatch&): Assertion
`pch == part_mid_buf + part_mid_buf_len' failed.
Aborted


Expected results:

PAN starts

Additional info:
Comment 1 Pavel Polischouk 2008-05-21 14:17:36 EDT
Created attachment 306290 [details]
Tasks.nzb causing corrupted double-linked list abort from glibc
Comment 2 Pavel Polischouk 2008-05-21 14:20:40 EDT
Debugged the problem further. It happens when trying to load a huge tasks.nzb
(around 95000 lines). When the file is split into two parts by copying and
removing extra <file>...</file> sections, each part loads successfully.
This most likely means state corruption in nzb parser by certain input.

Attaching the bad nzb files that cause: assertion, segmentation fault, or abort
inside glibc (double-linked list corruption detected).
Comment 3 Pavel Polischouk 2008-05-21 14:21:26 EDT
Created attachment 306292 [details]
Glibc-generated stack trace from abort
Comment 4 Pavel Polischouk 2008-05-21 14:24:08 EDT
Created attachment 306293 [details]
Tasks.nzb causing pan to segfault
Comment 5 Pavel Polischouk 2008-05-21 14:25:03 EDT
Created attachment 306294 [details]
Stack trace from segfault
Comment 6 Pavel Polischouk 2008-05-21 14:33:21 EDT
Created attachment 306296 [details]
Tasks.nzb causing assertion in pan.
Comment 7 Pavel Polischouk 2008-05-21 14:33:45 EDT
Created attachment 306297 [details]
Stack trace from assertion
Comment 8 Pavel Polischouk 2008-05-27 22:48:05 EDT
Found the root cause of the problem.

PartsBatch class has inconsistent storage for Parts. For each new batch, it does
not clear() the 'parts' variable, but only resize()s it if the new batch is
bigger (pan/data/parts.cc, lines 307 and 316). If the new batch is smaller than
the previous, extra entries are untouched.

The problem happens when pan attempts to sort the full vector
(pan/tasks/nzb.cc:128), thus possibly mixing the parts from the current batch
with the parts from the previous batches.

The solution is to clear() the 'parts' vector on each init(), then push_back()
the new parts in add_part, so the vector size always corresponds to the real
number of found parts.
Comment 9 Pavel Polischouk 2008-05-27 22:53:31 EDT
Created attachment 306880 [details]
Fix the assertion in PAN due to sorting of an array containing redundant elements

Added proper handling of PartBatch::parts vector.
Fixed allocation policy of Part::packed_mid element to re-allocate it every
time rather than trying to reuse a previous instance.

Signed-off by: pavelvp@inbox.ru
Comment 10 Pavel Polischouk 2008-05-27 23:40:28 EDT
Note that when compiled with -O0 for ease of debugging, abort or segfault never
happen, assertion always happens instead.
Comment 11 Josh Bressers 2008-05-28 13:59:44 EDT
I'm assigning this issue CVE-2008-2363.  From the look of this, it looks like a
pretty generic heap overflow, which means we can't rule out arbitrary code
execution.
Comment 12 Pavel Polischouk 2008-05-31 06:01:27 EDT
Added dependency on bug 433970.
Building pan rpm with this assertion fix for F9 is impossible without
compilation fixes here: https://bugzilla.redhat.com/attachment.cgi?id=306299
Comment 13 Tomas Hoger 2008-06-02 04:40:57 EDT
Moving to Security Response product, creating tracking bugs.
Comment 15 Vincent Danen 2012-05-24 17:37:28 EDT
Current Pan in Fedora is 0.135+ and this was fixed in 0.133 (http://pan.rebelbase.com/download/releases/0.133/).

Note You need to log in before you can comment on or make changes to this bug.