Bug 446902 (CVE-2008-2363)
Summary: | CVE-2008-2363 pan: heap overflow caused by large *.nzb files | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Pavel Polischouk <pavel.polischouk> |
Component: | vulnerability | Assignee: | Alexander Dalloz <alex> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | mpeters |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-05-24 21:37:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 449333, 449334, 449335 | ||
Bug Blocks: | |||
Attachments: |
Description
Pavel Polischouk
2008-05-16 16:01:51 UTC
Created attachment 306290 [details]
Tasks.nzb causing corrupted double-linked list abort from glibc
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). Created attachment 306292 [details]
Glibc-generated stack trace from abort
Created attachment 306293 [details]
Tasks.nzb causing pan to segfault
Created attachment 306294 [details]
Stack trace from segfault
Created attachment 306296 [details]
Tasks.nzb causing assertion in pan.
Created attachment 306297 [details]
Stack trace from assertion
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. 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
Note that when compiled with -O0 for ease of debugging, abort or segfault never happen, assertion always happens instead. 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. 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 Moving to Security Response product, creating tracking bugs. Current Pan in Fedora is 0.135+ and this was fixed in 0.133 (http://pan.rebelbase.com/download/releases/0.133/). |