This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• BMP file with a byte set to 0x01 instead of 0x00 (sail.bmp, image/bmp, 2019-02-20 22:40:42 +0000, 15858 bytes)

Reported in version: 1.2.15
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2019-02-20 22:40:42 +0000, Bastian Kanbach wrote:

Created attachment 3644
BMP file with a byte set to 0x01 instead of 0x00

Good evening,

I found a Heap Overflow vulnerability in file/SDL_rwops.c:336 which can be triggered when the "fread" operation reads from a malformed BMP file:

Adress Sanitizer Output:

=================================================================
==9065==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000002282 at pc 0x00000048e410 bp 0x7ffe296639b0 sp 0x7ffe29663160
WRITE of size 1 at 0x619000002282 thread T0
# 0 0x48e40f in __interceptor_fread.part.52 (/tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette+0x48e40f)
# 1 0x7fb998aa973e in stdio_read /tmp/libsdl1.2-1.2.15+dfsg2/./src/file/SDL_rwops.c:336:10
# 2 0x7fb998b6499d in SDL_LoadBMP_RW /tmp/libsdl1.2-1.2.15+dfsg2/./src/video/SDL_bmp.c:246:5
# 3 0x5271ae in main /tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette.c:178:19
# 4 0x7fb99868909a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
# 5 0x41b469 in _start (/tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette+0x41b469)

0x619000002282 is located 2 bytes to the right of 1024-byte region [0x619000001e80,0x619000002280)
allocated by thread T0 here:
# 0 0x4eabe7 in malloc (/tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette+0x4eabe7)
# 1 0x7fb998b75a9c in SDL_AllocFormat /tmp/libsdl1.2-1.2.15+dfsg2/./src/video/SDL_pixels.c:133:44
# 2 0x7fb998b8094c in SDL_CreateRGBSurface /tmp/libsdl1.2-1.2.15+dfsg2/./src/video/SDL_surface.c:102:20
# 3 0x7fb998b64449 in SDL_LoadBMP_RW /tmp/libsdl1.2-1.2.15+dfsg2/./src/video/SDL_bmp.c:224:12
# 4 0x5271ae in main /tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette.c:178:19
# 5 0x7fb99868909a in __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-buffer-overflow (/tmp/libsdl1.2-1.2.15+dfsg2/test/testpalette+0x48e40f) in __interceptor_fread.part.52
Shadow bytes around the buggy address:
0x0c327fff8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff8420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c327fff8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fff8450:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8470: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff8490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fff84a0: 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
==9065==ABORTING

The Proof-of-concept is attached to this bugreport.

Steps to reproduce:

1. Download SDL-1.2.15
2. CC="clang-7" CFLAGS="-g -O2 -fsanitize=address -fsanitize-coverage=trace-pc-guard" ./configure
3. make
4. sudo make install
5. cd test
6. CC="clang-7" CFLAGS="-g -O2 -fsanitize=address -fsanitize-coverage=trace-pc-guard" ./configure
7. make
8. echo -ne "\x01" | dd of=sail.bmp bs=1 seek=47 conv=notrunc
9. ./testpalette
10. ./loopwave PoC

On 2019-07-30 17:49:36 +0000, Ryan C. Gordon wrote:

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

On 2019-07-31 04:06:02 +0000, Ozkan Sezer wrote:

This seems to have been fixed in hg / SDL-1.2 branch. Using the
attached file here as sail.bmp, testpalette exits cleanly.

$ valgrind ./testpalette
==4723== Memcheck, a memory error detector
==4723== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4723== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4723== Command: ./testpalette
==4723==
SDL error: loading sail.bmp: BMP file has an invalid number of colors
==4723==
==4723== HEAP SUMMARY:
==4723== in use at exit: 90,156 bytes in 1,247 blocks
==4723== total heap usage: 14,782 allocs, 13,535 frees, 2,795,629 bytes allocated
==4723==
==4723== LEAK SUMMARY:
==4723== definitely lost: 40 bytes in 4 blocks
==4723== indirectly lost: 208 bytes in 8 blocks
==4723== possibly lost: 0 bytes in 0 blocks
==4723== still reachable: 89,908 bytes in 1,235 blocks
==4723== suppressed: 0 bytes in 0 blocks
==4723== Rerun with --leak-check=full to see details of leaked memory
==4723==
==4723== For counts of detected and suppressed errors, rerun with: -v
==4723== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 58 from 12)

On 2019-09-20 20:47:34 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:41 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.