codeblog code is freedom — patching my itch

September 28, 2007

CUPS banner template variables

Filed under: Networking,Ubuntu — kees @ 5:51 pm

A while back, I wanted to design some banner pages for a shared network printer that would show the name of the host that sent the request (none of the standard CUPS banners report this). It was easy enough to define a custom banner page:

<Printer lj4200>
...
JobSheets shared-banner none
...
</Printer>

Then, I could drop a modified banner into /usr/share/cups/banners with the filename “shared-banner”. The banner is just a regular PostScript file, so I could muck around with it. While looking at the “standard” banner, I saw some PS variables being used that had been defined by CUPS:

...
  (Job ID: ) RIGHT
  2 copy                % Copy X & Y
  moveto
  ({printer-name}-{job-id}) show
...

I couldn’t find documentation on the available variables, but managed to track down some of the list at cupsGetJobs2 in cups/utils.c:

job-id
job-priority
job-k-octets
job-state
time-at-completed
time-at-creation
time-at-processing
job-printer-uri
document-format
job-name
job-originating-user-name

None of these had the sending host listed, so I continued searching. Additional ones are defined in scheduler/ipp.c, including:

printer-name
job-id
job-billing
job-hold-until
job-sheets
job-media-sheets-completed
job-originating-host-name

“job-originating-host-name” did the trick for my banner:

...
  (Host: ) RIGHT
  moveto
  ({job-originating-host-name}) show
...

I’ve seen some other partial lists, but I haven’t found an official complete list. It’d be handy to see this documented better, since some variables aren’t valid until after the job is processed (job-sheets), so it’s only valid in the trailing banner, not the leading banner.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 27, 2007

stupid BIOS tricks to find your 4G of RAM

Filed under: Ubuntu — kees @ 7:36 am

A few months ago I upgraded my system to 4G of RAM. Blinded by my shiny new DIMMs, I never actually looked at the output of “free”. All I saw was that the system-monitor applet now showed lots of free memory. Only recently did I notice that I only had 3G of RAM, instead of my expected 4G. This is a rather common problem when running a 32bit OS, but I’ve been running 64bit for a while now. In fact, since it’s such a common complaint for 32bit OSes, I didn’t have any luck Googling for an answer. I did find references to chipset limitations (motherboards with only a 32bit memory bus), but “lshw” seemed to think I was okay. I had 4 banks each showing:

*-bank:0
description: DIMM DDR Synchronous 333 MHz (3.0 ns)

size: 1GB
width: 64 bits
clock: 333MHz (3.0ns)

On reboot, I also noted that my BIOS said I only had 3G. I started to get worried, but managed to find a setting on my Northbridge for Memory to enable “Hardware memory hole”. After that, both the BIOS and Linux were happy and seeing the full 4G. I assume the BIOS just bumps the memory in the 3G region to above 4G, which makes for a silly kernel message:

[ 24.617275] Memory: 3977852k/5259264k available (2281k kernel code, 150272k reserved, 1182k data, 300k init)

But I don’t care. :) It works now, and my “free” output makes me happy again:

             total       used       free     shared    buffers     cached
Mem:       3986156    3958396      27760          0      68268    2949472
-/+ buffers/cache:     940656    3045500
Swap:      3903672      38676    3864996

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 26, 2007

stupid dpkg tricks when fighting XFS bugs

Filed under: Ubuntu — kees @ 3:26 pm

A few days ago, I found myself with corrupted libraries and other insanity after doing a “dist-upgrade”. As it turns out, my filesystem was to blame. After running xfs_repair on it, I used a handy short-cut to re-install all the packages that might have gotten caught in the breakage:

sudo apt-get –reinstall install $(grep ^2007-09-24 /var/log/dpkg.log | cut -d\ -f4)

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 24, 2007

0x41 0x41 0x41 0x41

Filed under: Security,Ubuntu,Vulnerabilities — kees @ 8:34 pm

When trying to find buffer overflows, it is common practice to try and fill memory with lots of “A” characters. I first saw this when learning basic stack smashing techniques from Smashing the Stack for Fun and Profit, and have long wondered who did it first. Ever since, I’ve always used long strings of “A”s too (sometimes “B”s), and only recently started using better things like Metasploit’s pattern generator and offset reporter.

I’m fairly used to seeing things like this from my gdb sessions:

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb)

It means I’ve managed to gain control of the instruction pointer, and I’m now to the stage of needing to locate and deliver a shellcode.

Over the weekend I had the pleasure of causing my kernel to do something similar, via an unprivileged userspace process, using the vulnerability discovered by Wojciech Purczynski:

[119647.578349] general protection fault: 0000 [3] SMP
[119647.578357] CPU 0

[119647.578759] Code: Bad RIP value.
[119647.578774] RIP [<4141414141414141>]

I hadn’t had an opportunity to play with kernel shellcode before, so I ended up learning a lot from Brad Spengler. Before the day was up, I was left staring at a root shell.

This was a nasty bug. Luckily, it’s “only” a local exploit, and only for x86_64 kernels. But that’s still a very large number of installations. Please make sure your x86_64 machines are patched against CVE-2007-4573 (for Ubuntu, this is USN-518-1).

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 15, 2007

catching stack overflows in gdb as they happen

Filed under: Reverse Engineering,Security,Ubuntu — kees @ 8:57 pm

Recently I was trying to help debug a stack overflow crash in wpa_supplicant. The trouble with a stack crash is that you end up without a useful call history since the stack is left partially wrecked. The compiler code for detecting stack overflows (SSP), sets up a canary value between the local variables of the function and the stack frame. When the function exits, it tests this canary value and aborts if it doesn’t match what it is expecting. So, logically, to catch the stack overflow, gdb needs to be set up in a way to watch the canary location too. Since the canary is only valid while in the function, gdb must be set up to have a memory watch only when the function is called.

Here is the function preamble:

0x08081940 <wpa_driver_wext_get_scan_results+0>:        push   %ebp
0x08081941 <wpa_driver_wext_get_scan_results+1>:        mov    %esp,%ebp
0x08081943 <wpa_driver_wext_get_scan_results+3>:        push   %edi
0x08081944 <wpa_driver_wext_get_scan_results+4>:        push   %esi
0x08081945 <wpa_driver_wext_get_scan_results+5>:        push   %ebx

Save registers, prepare %ebp.

0x08081946 <wpa_driver_wext_get_scan_results+6>:        mov    $0x1000,%ebx
0x08081951 <wpa_driver_wext_get_scan_results+17>:       mov    0x8(%ebp),%eax
0x08081954 <wpa_driver_wext_get_scan_results+20>:       mov    0xc(%ebp),%edx
0x08081957 <wpa_driver_wext_get_scan_results+23>:       lea    0xffffffb0(%ebp),%esi

Make room for local variables, copy some function arguments and local variables into registers.

0x0808195a <wpa_driver_wext_get_scan_results+26>:       mov    %gs:0x14,%ecx
0x08081961 <wpa_driver_wext_get_scan_results+33>:       mov    %ecx,0xffffffec(%ebp)
0x08081964 <wpa_driver_wext_get_scan_results+36>:       xor    %ecx,%ecx

Here’s the stack canary getting set, and the register cleared. It’s saved at %ebp minus 0x14 (0xffffffec signed is -0x14):

(gdb) printf "0x%x\n", 0-0xffffffec
0x14

Now for the function play-out:

0x08081a37 <wpa_driver_wext_get_scan_results+247>:      mov    0xffffffec(%ebp),%edx
0x08081a3a <wpa_driver_wext_get_scan_results+250>:      xor    %gs:0x14,%edx
0x08081a41 <wpa_driver_wext_get_scan_results+257>:      jne    0x8081eae <wpa_driver_wext_get_scan_results+1390>

There is the canary check.

0x08081a47 <wpa_driver_wext_get_scan_results+263>:      add    $0xec,%esp
0x08081a4d <wpa_driver_wext_get_scan_results+269>:      pop    %ebx
0x08081a4e <wpa_driver_wext_get_scan_results+270>:      pop    %esi
0x08081a4f <wpa_driver_wext_get_scan_results+271>:      pop    %edi
0x08081a50 <wpa_driver_wext_get_scan_results+272>:      pop    %ebp
0x08081a51 <wpa_driver_wext_get_scan_results+273>:      ret    
...
0x08081eae <wpa_driver_wext_get_scan_results+1390>:     call   0x804bdc8 <__stack_chk_fail@plt>

Release local stack, pop saved registers and return. Nearer the end is the call to __stack_chk_fail when the canary doesn’t match.

So, to watch the canary, we need to set up a memory watch after it as been set, and tear it down before we leave the function. Respectively, we can use addresses 0x08081964 and 0x08081a3a (in bold above):

(gdb) br *0x08081964
Breakpoint 1 at 0x8081964
(gdb) br *0x08081a3a
Breakpoint 2 at 0x8081a3a

At the first breakpoint, we set a memory watch using a gdb-local variable, based on %ebp (we can’t use %ebp directly since it will change in lower function calls):

(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>silent
>set variable $cow = (unsigned long*)($ebp - 0x14)
>watch *$cow
>cont
>end

Since I couldn’t find an easy way to track the memory watch number that was created during the first breakpoint, I just built a gdb counter, and deleted the memory watch when leaving, since I could predict gdb’s numbering (first watch will be “3”, following our breakpoints 1 and 2):

(gdb) set variable $count = 3
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>silent
>delete $count
>set variable $count = $count + 1
>cont
>end

Now we can run, and wait for the canary to get overwritten:

(gdb) cont
Continuing.
Hardware watchpoint 3: *$cow
Hardware watchpoint 4: *$cow
...
Hardware watchpoint 12: *$cow
Hardware watchpoint 13: *$cow
Hardware watchpoint 13: *$cow

Old value = 4278845440
New value = 4278845546
0x0804eae6 in ?? ()

We see the canary value is 0xFF0A0000 getting it’s little-endian first byte overwritten to FF0A006A. We catch it before it has wrecked the stack, and we can see very clearly where we are:

(gdb) bt
#0  hexstr2bin (hex=0x080a239d "6151663870517a74", buf=0x080a2395 "aQf8pQzt00000000j", len=8)
    at ../src/utils/common.c:88
#1  0x08082297 in wpa_driver_wext_get_scan_results (priv=0xb7dd816c, 
    results=0x080a239d, max_size=0x79)
    at ../src/drivers/driver_wext.c:1383
...
(gdb) x/1i $eip      
0x804eae6 <hexstr2bin +54>:      addl   $0x1,0xfffffff0(%ebp)

On a closer look at the source, we realize wext_get_scan_custom got inlined into the function (it was static and only called from one place, so the compiler optimized it). Further tracking in the source shows that the “16” value passed in should actually be “8” (the limit of the destination, not the source, buffer size).

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

Powered by WordPress