[1days] [0days] [PoCs] More gstreamer FLIC / vmnc issues

OverviewA part of any intellectually honest full disclosure experiment is to disclose the less interesting findings alongside the more serious issues and exploits.Accordingly, if you were looking for spectacular 0day exploits, this is not the post you …

Overview
A part of any intellectually honest full disclosure experiment is to disclose the less interesting findings alongside the more serious issues and exploits.

Accordingly, if you were looking for spectacular 0day exploits, this is not the post you are looking for. If you’re generally interested in software failure conditions, though, here’s a bunch.
While looking at the gstreamer FLIC and vmnc decoders, I noticed various other issues aside from the ones that have already been blogged about. Some of these issues are also serious while others are trivial. For most of the issues, I have to commend the gstreamer team on a great job looking for variants of my initial post and in particular giving the FLIC decoder a thorough examination. For many security “fixes”, a project or vendor will just patch up the immediate issues reported, but gstreamer looked at the surrounding area of the initial fault and patched up many additional issues independently. Therefore, most of the vulnerabilities disclosed in this post are now 1days and not 0days.

1: FLIC decoder: uninitialized output canvas
(CESA-2016-0005)
Looks like it’s still an 0day. Images are from Fedora 25 with all updates applied.

This one goes first because it is nice and visual. The bug is that the output canvas is allocated but not initialized. Therefore if you have a file that does not start off by clearing the screen, or rendering an entire first frame, you will have uninitialized heap memory in the output canvas. It looks kind of pretty. Is that pointers I see? :-)

flx_uninit1.png
flx_uninit2.png

2: FLIC decoder: out-of-bounds writes in FLX_SS2 command
(CESA-2016-0006)
A near identical vulnerability to the one I exploited in the FLX_LC command. Caught and fixed by gstreamer upstream; patched in latest Ubuntu and Fedora updates.

3: FLIC decoder: integer underflow and subsequent wildness in FLX_BRUN command
(CESA-2016-0007)
Caught and fixed by gstreamer upstream; patched in latest Ubuntu and Fedora updates.

The faulty code:

 gulong count, lines, row;
...
   row = flxdec->hdr.width;
   while (row) {
     count = *data++;

     if (count > 0x7f) {
       /* literal run */
       count = 0x100 - count;
       row -= count;

       while (count--)
         *dest++ = *data++;

As you can see, no consideration was given as to whether any “run count” is in fact greater than the remaining number of pixels in a row. If that happens, integer underflow will occur on the row variable, which will become a very large (2^64 on 64-bit) positive integer. The loop will continue and suffer from buffer overflow on the output canvas and buffer overread on the input buffer. With no obvious way to exit the wild copy loop, exploitation is not favored.

4: FLIC decoder: out-of-bounds read with wild chunk size
(CESA-2016-0008)
In general, the FLIC decoder lacked any defences for reading off the end of the input buffer. Tons of bugs here. But a gstreamer rewrite to avoid raw pointer access and use buffer object APIs for reading and writing seems to have fixed this area reasonably. Bravo.

The most obvious way to demonstrate this was to declare a chunk in the file with a huge size. The input pointer would be incremented by this size and then the next chunk header read from a wild location, leading to a crash.

5: FLIC decoder: integer overflow in output buffer allocation
(CESA-2016-0009)
Looks fixed in the code; untested.

This bug is more interesting than it first appears. The faulty line of code is simple enough:

        out = gst_buffer_new_and_alloc (flxdec->size * 4);

But what type is flxdec->size?

struct _GstFlxDec {
 gsize size;

Where gsize appears to be like a size_t.
So this is one of those interesting cases this is a vulnerability on 32-bit but ok on 64-bit. On 64-bit, the largest value of size was 0xffff * 0xffff. Multiplying again by 4 cannot exceed the width of a 64-bit type. On 32-bit, integer overflow is possible and results in a memory corruption, although a fairly wild one!

6: vmnc decoder: wild read due to integer overflow
(CESA-2016-0010)
Fixed, possibly as an accidental side effect of fixing the more serious integer overflow CESA-2016-0002.

if (type == CURSOR_COLOUR) {
   datalen += rect->width * rect->height * dec->format.bytes_per_pixel * 2;
...
 if (len < datalen) {
   GST_LOG_OBJECT (dec, "Cursor data too short");

A simple integer overflow in calculating how much input data is required for a cursor of a given size.

Closing notes
Bugs bugs glorious bugs.


[1days] [0days] [PoCs] More gstreamer FLIC / vmnc issues

OverviewA part of any intellectually honest full disclosure experiment is to disclose the less interesting findings alongside the more serious issues and exploits.Accordingly, if you were looking for spectacular 0day exploits, this is not the post you …

Overview
A part of any intellectually honest full disclosure experiment is to disclose the less interesting findings alongside the more serious issues and exploits.

Accordingly, if you were looking for spectacular 0day exploits, this is not the post you are looking for. If you’re generally interested in software failure conditions, though, here’s a bunch.
While looking at the gstreamer FLIC and vmnc decoders, I noticed various other issues aside from the ones that have already been blogged about. Some of these issues are also serious while others are trivial. For most of the issues, I have to commend the gstreamer team on a great job looking for variants of my initial post and in particular giving the FLIC decoder a thorough examination. For many security “fixes”, a project or vendor will just patch up the immediate issues reported, but gstreamer looked at the surrounding area of the initial fault and patched up many additional issues independently. Therefore, most of the vulnerabilities disclosed in this post are now 1days and not 0days.

1: FLIC decoder: uninitialized output canvas
(CESA-2016-0005)
Looks like it’s still an 0day. Images are from Fedora 25 with all updates applied.

This one goes first because it is nice and visual. The bug is that the output canvas is allocated but not initialized. Therefore if you have a file that does not start off by clearing the screen, or rendering an entire first frame, you will have uninitialized heap memory in the output canvas. It looks kind of pretty. Is that pointers I see? :-)

flx_uninit1.png
flx_uninit2.png

2: FLIC decoder: out-of-bounds writes in FLX_SS2 command
(CESA-2016-0006)
A near identical vulnerability to the one I exploited in the FLX_LC command. Caught and fixed by gstreamer upstream; patched in latest Ubuntu and Fedora updates.

3: FLIC decoder: integer underflow and subsequent wildness in FLX_BRUN command
(CESA-2016-0007)
Caught and fixed by gstreamer upstream; patched in latest Ubuntu and Fedora updates.

The faulty code:

 gulong count, lines, row;
...
   row = flxdec->hdr.width;
   while (row) {
     count = *data++;

     if (count > 0x7f) {
       /* literal run */
       count = 0x100 - count;
       row -= count;

       while (count--)
         *dest++ = *data++;

As you can see, no consideration was given as to whether any “run count” is in fact greater than the remaining number of pixels in a row. If that happens, integer underflow will occur on the row variable, which will become a very large (2^64 on 64-bit) positive integer. The loop will continue and suffer from buffer overflow on the output canvas and buffer overread on the input buffer. With no obvious way to exit the wild copy loop, exploitation is not favored.

4: FLIC decoder: out-of-bounds read with wild chunk size
(CESA-2016-0008)
In general, the FLIC decoder lacked any defences for reading off the end of the input buffer. Tons of bugs here. But a gstreamer rewrite to avoid raw pointer access and use buffer object APIs for reading and writing seems to have fixed this area reasonably. Bravo.

The most obvious way to demonstrate this was to declare a chunk in the file with a huge size. The input pointer would be incremented by this size and then the next chunk header read from a wild location, leading to a crash.

5: FLIC decoder: integer overflow in output buffer allocation
(CESA-2016-0009)
Looks fixed in the code; untested.

This bug is more interesting than it first appears. The faulty line of code is simple enough:

        out = gst_buffer_new_and_alloc (flxdec->size * 4);

But what type is flxdec->size?

struct _GstFlxDec {
 gsize size;

Where gsize appears to be like a size_t.
So this is one of those interesting cases this is a vulnerability on 32-bit but ok on 64-bit. On 64-bit, the largest value of size was 0xffff * 0xffff. Multiplying again by 4 cannot exceed the width of a 64-bit type. On 32-bit, integer overflow is possible and results in a memory corruption, although a fairly wild one!

6: vmnc decoder: wild read due to integer overflow
(CESA-2016-0010)
Fixed, possibly as an accidental side effect of fixing the more serious integer overflow CESA-2016-0002.

if (type == CURSOR_COLOUR) {
   datalen += rect->width * rect->height * dec->format.bytes_per_pixel * 2;
...
 if (len < datalen) {
   GST_LOG_OBJECT (dec, "Cursor data too short");

A simple integer overflow in calculating how much input data is required for a cursor of a given size.

Closing notes
Bugs bugs glorious bugs.


Thieves can guess your secret Visa card details in just seconds

Enlarge / A website bot as it distributes CVV guesses over multiple sites. (credit: Ali, et al.)
Thieves can guess your secret Visa payment card data in as little as six seconds, according to researchers at Newcastle University in the UK. Bad actors…

Enlarge / A website bot as it distributes CVV guesses over multiple sites. (credit: Ali, et al.)

Thieves can guess your secret Visa payment card data in as little as six seconds, according to researchers at Newcastle University in the UK. Bad actors can use browser bots to distribute guesses across hundreds of legitimate online merchants.

The attack starts out with a card's 16-digit number, which can be obtained in a variety of ways. Attackers can buy numbers on black-market websites, often for less than $1 apiece, or use a smartphone equipped with a near-field communication reader to skim them. The numbers can also be inferred by combining your first six digits—which are based on the card brand, issuing bank, and card type—with a verification formula known as the Luhn Algorithm. Once an attacker has a valid 16-digit number, four seconds is all they need to learn the expiration date and the three-digit card-verification value that most sites use to verify the validity of a credit card. Even when sites go a step further by adding the card holder's billing address to the process, the technique can correctly guess the information in about six seconds.

The technique relies on Web bots that spread random guesses across almost 400 e-commerce sites that accept credit card payments. Of those, 26 sites use only two fields to verify cards, while an additional 291 sites use three fields. Because different sites rely on different fields, the bots are able to enter intelligent guesses into the user field of multiple sites until the bots hit on the right ones. Once the correct expiration date is obtained for a given card—typically banks issue cards that are valid for up to 60 months—the bots use a similar process to obtain the CVV number. In other cases, when sites allow the bots to obtain the CVV first—a process that can never require more than 1,000 guesses—the bots then work to obtain the expiration date and, if required, the billing address.

Read 6 remaining paragraphs | Comments

Minion – Mozilla Security Testing Framework

Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan with a wide variety of security tools, using a simple HTML-based interface. It consists of three …

Minion is a security testing framework built by Mozilla to bridge the gap between developers and security testers. To do so, it enables developers to scan with a wide variety of security tools, using a simple HTML-based interface. It consists of three umbrella projects: Minion Frontend, a Python, angular.js, and Bootstrap-based website that...

Read the full post at darknet.org.uk