After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 762417 - Out of bounds read in function token_stream_prepare() triggered by test suite
Out of bounds read in function token_stream_prepare() triggered by test suite
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gvariant
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-02-21 23:10 UTC by Hanno Böck
Modified: 2016-02-22 14:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch / fix (531 bytes, patch)
2016-02-21 23:10 UTC, Hanno Böck
none Details | Review
full address sanitizer error message / stack trace (3.16 KB, text/plain)
2016-02-21 23:10 UTC, Hanno Böck
  Details

Description Hanno Böck 2016-02-21 23:10:05 UTC
Created attachment 321796 [details] [review]
proposed patch / fix

Running "make check" with glib when compiled with Address Sanitizer shows an out of bounds error in the file gvariant-parser.c (line 240), function token_stream_prepare().

This is the code in question:
      for (end = stream->stream + 1;
           end != stream->end && *end != ',' &&
           *end != ':' && *end != '>' && *end != ']' && !g_ascii_isspace (*end);
           end++)

What happens is that stream->end is not really set to the end of the stream (it's zero, set in g_variant_new_parsed_va(), line 2461). Therefore the end of the string is not detected.

I have attached a patch to fix this, but I propose someone more familiar with this code checks if this is a good way to fix it. I add an additional check for a terminating null byte in the for condition.
Another way to fix this would be to make sure that stream->end is always set to a valid value (could be done in line 2461 by using "format + strlen(format)"), but as this function is called from various other functions I'm not sure this is wanted and it seems the code is written in a way that it expects that the stream end can be set to zero.
Comment 1 Hanno Böck 2016-02-21 23:10:33 UTC
Created attachment 321797 [details]
full address sanitizer error message / stack trace
Comment 2 Allison Karlitskaya (desrt) 2016-02-22 12:59:21 UTC
This is a fairly serious issue.  I'm treating this as a security bug, because there's this:

desrt@humber:~$ dconf write /x '%i'
Segmentation fault


and we can imagine that any similar tool that parses GVariant from untrusted sources could have similar issues.
Comment 3 Allison Karlitskaya (desrt) 2016-02-22 14:17:55 UTC
Okay.  Pushed to master and backported to the last several stable branches as well.

After discussion with the Ubuntu security team, I've decided that this issue isn't so serious: it doesn't allow code execution in any circumstances and there are no known places (and certainly no popular places) where this could even be exploited for a DoS.

Thanks for the patch.