Security considerations: Robe of Glib Security

Stupid pun against the Robe of Glib Tongues which is an item found in the Oblivion game. You can read it either literally or related to the actual glib library.

So yesterday the advisory was published of a (very far-fetched) glib security issue I found some time ago. I’m no security expert, although I have written about the topic from time to time. I sincerely wasn’t really in the known about security tasks before joining Gentoo, it has been the contact with our security team, dealing with packages with security issues, and then working with xine that let me understand a bit better what the problems are with security and software. The way I found this issue has been quite.. homebrew.

At the time I was working on benchmarking glib to evaluate whether to use them or FFmpeg’s routines in lscube projects (at the end I went for glib’s mostly because we ended up using a lot of glib code already). During that evaluation, I noticed a crash in glib when using a huge text file, and after looking that up, it shown that it was really an overflow.

I’ll leave you to the advisory for the details of what the problem is exactly, but I’m going to tell you that doing a quick check around the glib sources, similar situations are all too common, mixing the 32-bit guint type with the platform-specific gsize type, which can cause similar overflows and similar security issues. Does this mean that glib is unsafe? To an extent, yes.

The problem here is that we have a quite commonly used library, that is indeed used in a vast range of applications and is probably quite widely available on embedded applications too, including Nokia’s devices. This library is in dire need of a security audit, and I hope this particular security issue, almost insignificant for the real users, would work fine as a warning light for it.

I’m sure somebody will scream that glib is just overcomplex and that developers should just reinvent the wheel every time they need to just to make sure they don’t suffer from others’ security bugs; on the other hand I’d like to say that the same problem that I found on glib by chance can easily be present in other software; and often times it is. Even FFmpeg suffers from similar problems, and yet reimplementing its features does not make it much better; for instance xine has had problems with code that implements the same demuxers as FFmpeg, even though with partially rewritten code. Similarly, VLC took the RealPlayer/RTSP library from xine, and they both suffer from the same kind of problems even though both have been evolving independently.

My suggestion, if anybody is concerned about similar overflows in their software, is to enable the -Wconversion flag, and make sure that there are no conversion problems; this should also find whenever strlen() return values are stored in non-size_t variables (which would then be smaller than the retuned value). The day when all the software will build with -Werror=conversion, will be the day when this kind of overflows will be quite less likely to appear. And while this can often be a very far fetched security issue, it does show that there is not enough security knowledge in our ecosystem.