Win Free Registration to CanSecWest

Hi,

Help us design our (CanSecWest)link t-shirt and win a free registration to the event plus $250 for expenses.

We will be giving away a t-shirt to booth visitors and if your idea is the best we will use it at the show.

The design should be in one color and fit on the back of the shirt. It can be something related to network security and could be text, an image or a cartoon.

Not planning to go to CanSecWest? Send in your idea anyway. If we use it we’ll send you the $250 and give the ticket to the second place design.

Noam.

CanSecWest 2011

Hi guys,

We will be attending and sponsoring CanSecWest 2011. As part of the sponsorship we will invite a few of our readers of the blog to join us by giving out a free entry pass. Stay tuned for more details to be released in a few days.

Just in case you don’t know what CanSecWest is all about see:
CanSecWest, focusing on applied digital security, will bring industry luminaries together in a relaxed environment which promotes collaboration and social networking. The conference features a single track of thought provoking presentations, each prepared by an experienced professional and talented educator who is at the cutting edge of his or her field. We give preference to new and innovative material, highlighting important, emergent technologies, techniques, or best industry practices.

Noam.

The casting case

No, this isn’t a post on theater :) rather it is an interesting case of how a number gets “casted” from different types effectively bypassing safety checks and finally causing a crash to occur – and possibly the execution of code, as the memmove function is called with an overly large value to use for copying.

It starts of with a program receiving a value of -2147483648 as the length, why is this value important? it has certain characteristics to it which is important:
1) It had to be negative
2) It had to be fairly large as it needs to overflow the a variable of a type of int
3) It couldn’t be too large as there were checks just before it to make sure it was too big

This magic number is not accidental it is actually (if you look at it in hex) it is the 0x80000000 equivalent, i.e. it is the negative representation of this number. So as soon as you cast it to “unsigned int”, it looks positive, and when you cast it to just “int” it looks negative.

So if you programmed your code to do a check, and you didn’t make sure you casted the value when you did the check, for example you did:
if (con->content_len < buffered_len)

Where content_len is an "int", while you are comparing to an "unsigned int" value, the comparison will be flawed and the check will be true, even if the value being passed is negative and should be discarded.

Further, if you then call:
memmove(conn->buf, conn->buf + conn->request_len, conn->content_len);

The memmove’s last parameter is defined as an “unsigned int”, which in turn will cause this code to copy a positive value, rather then a negative value (not sure this would have helped in this case…), and in our scenario a very large memmove copy – which causes of course an Access Violation as the function reads data it shouldn’t be able to access.

This type of vulnerability and others like it can be easily detected by using beSTORM fuzzer, as it has the inherited capabilities of checking the relationships of values and their length, such as in this case.

UPDATE: My mistake on the example, my copy-paste skills were a bit flawed in this… I placed the patched version instead of the unpatched one.. causing the mixup, thanks for pointing it out jduck.

Fuzzing GTP-U

We were asked by one of our customers to provide them with a beSTORM GTP-U fuzzer module. Opening the spec and taking a peek of it revealed that it is a relatively straight forward protocol, though quite well documented, finding the documentation itself is quite hard – as there are multiple specs, which define various “versions” (more like revisions) of the protocol, spanning the 15 years of history behind this protocol.

As this protocol is not currently endorsed by IETF, but rather by the 3GPP group, if you seek the specification for the GTP-U protocol look up 3GPP TS 29.060, it has what you need.

Once we finished building the module we ran some test, it doesn’t look good for the GTP implementors, I guess lack of tools for testing, fuzzing and compliance checking of the GTP infrastructure left a lot of room for the security players to come in and bash their heads.

Good luck with your GTP fuzzing!