I reviewed libsdl2 2.0.14+dfsg2-3 as checked into impish. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
libsdl2 is a replacement for libsdl1.2 and provides abstractions over
access to video devices, audio, and input devices, often used by games or
game engines and other applications wishing to provide user interfaces.
- CVE History:
- 16 historical CVEs over a large code-base written in C
- I expected more to be honest so this is encouraging
- Build-Depends
- Large list of depends, none out of the ordinary or sensitive
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- 1 binary in PATH from the libsdl2-dev package:
- -rwxr-xr-x root/root 1307 2021-01-19 01:05 ./usr/bin/sdl2-config
- this is equivalent of pkg-config and is used to get cflags/ldflags etc
when compliling and application against libsdl2
- No sudo fragments
- No polkit files
- No udev rules
- No cron jobs
- unit tests / autopkgtests
- No unit tests run during build that I could see but autopkgtests
include a basic test to ensure compiling against libsdl2-dev works via
both cmake and using pkg-config directly
- Build logs:
- Lots of doxygen related noise in the build logs but nothing of note.
- No Processes spawned
- Memory management is all manual
- libsdl2 is written in C so all memory management is done manually,
however looking over a sample of the code this looks relatively careful
and defensive. There were some instances where callers would not check
for a NULL return value on memory allocation (which could occur when no
memory is available), however this likely would only lead to a crash on
a NULL ptr dereference in subsequent code and hence a denial-of-service
but given these cases occur when low on memory anyway the impact is not
much different so they are not too concerning.
- File IO
- Open joystick device-files etc and these are names are detected by
walking sysfs etc so are safe from untrusted input
- Logging appears to be careful to avoid format string vulns etc
- Uses lots of environment variables to allow to specify various device
names or even location of configuration files etc. Whilst they might be
able to be abused by the user of the library, since libsdl2 is a library
it does not have elevated privileges to cause any effect as a result so
this is generally not likely to be an issue.
- Lots of use of privileged functions (e.g. ioctl()) but this is expected
and again not likely able to cross any security boundary
- No use of cryptography / random number sources etc
- No use of temp files
- No obvious use of networking
- No use of WebKit
- No use of PolicyKit
- No significant cppcheck results
- A large number of issues reported by Coverity, most are likely false
positives or perhaps of low impact, again since the use of libsdl2 does
not cross a privilege boundary
For a very large library written in C, libsdl2 is in better shape than I
had feared. The extensive use of manual memory management and the handling
of various APIs and devices means there would be a lot of scope for errors
but I did not see any evidence of anything that would give me significant
cause for concern.
Security team ACK for promoting libsdl2 to main.
** Tags added: security-review-done
** Changed in: libsdl2 (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1256185
Title:
[MIR] libsdl2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1256185/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
