So mouting an iso in windows was kinda annoying. XP doesnt natively support it and so I had to resort to using daemontools (which installs other crapware (spyware/adware)).
Anyways, I just ran into Microsoft virtual cd control panel. As far as I can tell it’s totally free. and it’s use is trivial!
you can download it at:
http://download.microsoft.com/download/7/b/6/7b6abd84-7841-4978-96f5-bd58df02efa2/winxpvirtualcdcontrolpanel_21.exe
A while ago a minix advisory got released about a pre-auth remote root vulnerability in the minix ftpd:
http://minix1.woodhull.com/news/ftpsecadv.html
the advisory intentionally left out the details so people running minix wouldn’t get hurt. The most hilarious part about that advisory is that they mention it also affected minix 3 AFTER it got fixed, since they shipped the vuln. binary with minix 3 by accident.
Since I indepentantly discovered this bug about 2 years ago, let me fill you in on the details, the minix ftpd implements site crc, which basicly gives you the crc32 of a file. The first bug (or feature, whatever) is that you can call that without logging in. The 2nd and totally idiotic bug is that it does the following:
system(”/bin/crc32 “);
This falls in the “I can’t believe they fucked it up” category.
I have it from reliable sources that ALL 3 minix boxes on the internet got compromised this way.
So I was looking for the original advisory on the tenex password hack (I couldn’t find it, so if you know where it is, please leave a comment or email me). I did however run into rather interesting slides documenting -among other things- the tenex password hack.
http://www.st.cs.uni-sb.de/edu/secdesign/coding.pdf
it also discusses other security issues and then gives a more secure solution, what’s funny about ALL of the secure solutions is that they all touch memory after it’s been free()’d !!!, yea, that’s really secure …
Back to the tenex password hack tho, I’ve been thinking about this. I think you can also use it on hashes. Suppose you have a program like passwd, and have some nice rainbow tables at your disposal, you could use the tenex password hack to figure out the hash, and hence get the password (since you’re already using these rainbow tables :)).
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/getcwd.c.diff?r1=1.14&r2=1.15&f=h
OpenBSD’s getcwd implementation used to contain a double free(). Actually it was a double closedir(), which is just a wrapper for free(). The funny thing about that bug is that it was introduced when fixing a memory leak:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/getcwd.c.diff?r1=1.2&r2=1.3&f=h
NetBSD used to have this leak aswell, however it appears as if the OpenBSD guys never told them about it (I think back then they weren’t really talking to each other). The NetBSD guys accidentally fixed that memory leak the exact same way the OpenBSD guys fixed the double free(), replacing the libc getcwd() implementation with a systemcall.
http://www.pine.nl/press/pine-cert-20030101.txt
http://seclists.org/lists/vuln-dev/2002/Nov/att-0056/0
http://www.security-express.com/archives/bugtraq/2000-01/0012.html
In my previous post I talked about this whole downplaying thing. I was just reading some secunia advisories and ran into: http://secunia.com/advisories/20349/
“The vulnerability is cause due to a memory corruption error in the “dentry_unused” list within the “prune_dcache()” function”. So you’re telling me you get to corrupt memory, AND IT’S JUST A DENIAL OF SERVICE ? are you crazy ?
Here’s a little tip for people who are forced to make advisories, if an attacker can corrupt memory, assume it’s exploitable!, what happens if you dont ?
http://www.securityfocus.com/archive/1/394315/30/0/threaded
http://www.securityfocus.com/archive/1/394413/30/0/threaded
http://www.securityfocus.com/archive/1/394318/30/0/threaded
http://www.securityfocus.com/archive/1/439483 “The first allows any local user to fill up file systems by causing core dumps to write to directories to which they do not have write access permissions”
When I read that I was like “Hold on a minute, so you’re telling me I can put a file -of which I control large chunks- anywhere on the system, and this is just a DoS ?”. I didn’t actually investigate this is detail, since I had more important things to do, but here’s What I was thinking, have a symlink to /etc/ld.so.preload, then coredump to that symlink (assuming that codepath in the kernel follows symlinks). Last time I checked the gnu dynamic linker is very flexible about that file. basicly it’ll just go line by line till it finds a lib that works. I don’t know is this will acutally work, but I’m sure it’s something like that.
Then, this morning I read the dailydave mailing list and saw: http://lists.immunitysec.com/pipermail/dailydave/2006-July/003293.html
So the immunitysec guys made an exploit for it, and refering to Paul Starzetz. Later today I ran into http://www.securityfocus.com/archive/1/439610, where Paul states it really is exploitable.
He makes another good point in that post: ” really wonder why in the recent past there is a tendence to declare such things as “denial of service” etc – while they are perfect root backdoors / vulns”
That’s been annoying me a little bit lately, and it’s not just the linux kernel guys, A lot of people have been downplaying bugs (either knowingly -lying- or not -incompetence-). It’s even worse then that. When (some) people don’t realize something is exploitable, they tend not to fix it. Although they usually acknowledge it’s some sort of coding bug. For example, a few weeks ago I mailed some linux vendors regarding a bug is passwd, namely not checking the return value of setuid(). Someone mailed me back stating: “You know, we don’t know if this is actually exploitable, and I don’t want to go fix all of these bugs, So if you can’t provide me with a ./hackroot exploit, I won’t fix it”. Honestly, I think this is unacceptable, Wether or not a bug is exploitable it’s still a bug, so JUST FIX THE DAMN BUG! more often then not bugs turn out to be exploitable.
It would appear the list of people who should be banned from programming was pretty popular, hence a little update:
- BuGless AKA Stephen R. van den Berg (procmail)
- Greg A. “Don’t worry though — it’s definitely not exploitable” Woods (smail 3)
- Philip Hazel (exim)
- Matt Wright (formmail, wwwboards)
- Rasmus Lerdorf (php)
A while ago I spend some time in the osx heap allocator. Man there is so much crap in there, unbelieable.
One of the things I ran across was that their realloc implementation will never resize to something smaller. While technically this isn’t a violation of the c standard it’s still pretty retarded.
One other surprising thing I found was that their calloc code in older versions fuckedup boundschecking for 64-bit: http://cvs.opendarwin.org/cgi-bin/cvsweb.cgi/Libc/gen/malloc.c?rev=1.1.1.1&content-type=text/x-cvsweb-markup&cvsroot=apple
#define MAX_ALLOCATION 0xc0000000 // beyond this, assume a programming error
…
void *malloc_zone_calloc(malloc_zone_t *zone, size_t num_items, size_t size) {
void *ptr;
if (malloc_check_start && (malloc_check_counter++ >= malloc_check_start)) {
internal_check();
}
if (((unsigned)num_items >= MAX_ALLOCATION) || ((unsigned)size >= MAX_ALLOCATION) || ((long long)size * num_items >= (long long) MAX_ALLOCATION)) {
/* Probably a programming error */
fprintf(stderr, “*** malloc_zone_calloc[%d]: arguments too large: %d,%d\n”, getpid(), (unsigned)num_items, (unsigned)size);
return NULL;
}
ptr = zone->calloc(zone, num_items, size);
if (malloc_logger) malloc_logger(MALLOC_LOG_TYPE_ALLOCATE | MALLOC_LOG_TYPE_HAS_ZONE | MALLOC_LOG_TYPE_CLEARED, (unsigned)zone, num_items * size, 0, (unsigned)ptr, 0);
return ptr;
}
Incase you don’t spot the bug here, size_t is 64 bit (on 64-bit machines), but a cast to unsigned means unsigned int which is 32 bits long !!! hence there can be truncation later on !
in new versions they just removed the boundscheck, I kid you not, you just can’t make this stuff up.
In the older versions malloc and the like had the same flawed lengthcheck which doesn’t make sense at all !!!! you shouldn’t do boundschecking on the length at this level. the app that uses malloc should do it. The only thing you might want to check for is int overflow. Speaking of this limitation, the OpenBSD kernel memory allocator has very simular behavior, but only even more retarded:
void *
malloc(unsigned long size, int type, int flags)
{
struct kmembuckets *kbp;
struct kmemusage *kup;
struct freelist *freep;
long indx, npg, allocsize;
int s;
caddr_t va, cp, savedlist;
… some debug crap …
if (size > 65535 * PAGE_SIZE)
panic(”malloc: allocation too large”);
…
}
for those who can’t read c code, what this means is, if you tell malloc to allocate a really big chunck it will instead kernel panic. bug or feature ? I guess it was ok to do this in 1975, but It’s 2006 for fucks sake. ofcourse netbsd suffers from the same bug/feature. Not too long ago you could trigger this from the ELF loading code and I believe there are still some obsd drivers that allow you to trigger it.
In light of the whole calloc fuckup I started doing some googling, since I remember an advisory being published about this several years ago. http://cert.uni-stuttgart.de/advisories/calloc.php. Someone made the connection with fread and fwrite and it turns out they also contain a simular int overflow. since the osx guys stole fread/fwrite from FreeBSD, I checked fbsd and it appeared to have this int overflow. Then I figured I’d check openbsd which also has this int overflow. What’s somewhat more worrysome is that obsd’s fread and fwrite are NOT thread-safe especially since obsd recently got a whole new threading implementation: http://www.openbsd.org/papers/eurobsd2005/tedu-rthreads.pdf. I figured I’d check the obsd manpage for fread and fwrite and see if they mention that it’s not thread-safe. but they didn’t, infact, their fread and fwrite manpage hasn’t been update since 1994 !!!! It should come as no surprise that netbsd has the same int overflow issue. I didn’t even try to check glibc, I still want to hold on to my sanity for a while :)
SMALL UPDATE: There is some discussion on the netbsd current-users mailing list about this. Some seem to have misinterpreted my posting. The osx and NetBSD userland allocator have pretty much nothing in common and I wasn’t hinting towards that. But the (older version of) osx userland allocator and NetBSD/OpenBSD kernel allocator have 1 thing in common, namely a check like
if (size > something) bailout;
which imo doesn’t make sense at all especially if “bailout” is a kernel panic ! The other thing I mentioned about NetBSD was an int overflow in their fread and fwrite implementation. I made no other statements about NetBSD.
you pour some liquid in a laptop ?
I’m sure most have heard the theory that if you do that it dies. So I went to my lab and did some experiments. Turns out that it does effectively die. Although, I did not try it with water but with beer, I wonder if that makes a difference.
So I go to lenovo.com and order my brand new thinkpad x60 laptop. And since I want it to be here fast I said I want 2-day shipping. AND THE FUCKING ESTIMATED TIME TO SHIP IS THE 14TH OF THIS FUCKING MONTH !!!
HOW LONG DOES IT TAKE TO ASSEMBLE A FREAKING LAPTOP ???? 2 WEEKS ? WTF ARE THESE GUYS DOING ?
Needed to get that off my chest, I feel better now.