Architecture Diversity: A Security Perspective

By Brian Hatch, ITworld |  News

At the end of May, I left my claustrophobic apartment in Silicon Valley
for our grand move to Seattle. No, I'm not going there to work for
Microsoft, thank you (Good Linux/Unix suggestions welcome, however...).
It was a sad day. No, I wasn't sad to be leaving the horrible heat, the
strip-mall-ville skyline, or the land of a thousand midriffs. Good
riddance, I say. I was mourning the moment when I would power off my
machines and put them in boxes for the big move.

Four machines, each with uptimes of a year or more. Sure, I had to
reboot for a kernel upgrade now- and-then just like the next guy, but
that's it in the Linux and Unix world. Take that, Bill. (Whoops, I guess
he's a neighbor now.) My machines had performed flawlessly, through
blackouts and earthquakes [1]. However, one machine that had been
running the most smoothly was the one that was failing to do its
function.

I'd set up a honeypot on one of the systems. It was running a two year
old intentionally-outdated Linux distro full of bugs and instant-root
holes. In the year it'd been running, no one had gotten in.

I had an IDS set up to watch the network and, with extensive host
logging enabled, I could see that tons of attempts to break in had
occurred. Most of the daemons were running with holes -- old Wu-FTPd,
POP and IMAP bugs -- pretty much everything but Apache had some problem
that should have been exploitable to grant you shell access. Quite a few
brute-force password cracking attempts were made, but I did have strong
or locked passwords on all accounts, so I didn't expect those to
succeed.

So what was keeping all these buggy programs from being exploited? The
machine was running Linux, but not on a PC. Instead, I'd installed it on
the only spare machine I had: an old Sparc 5.

All the entry points were buffer overflows and format string bugs. Most
of the attacks were simple automated exploit scripts built from exploits
or proof-of-concepts that were released to BugTraq and other full
disclosure locations. Most of the code released to these venues tries to
prove a vulnerability can be exploited, but only concentrates on the
most popular Linux computer architecture: the x86 CPU.

Sun Sparcs use a completely different CPU architecture. A compiled
binary on a PC won't run whatsoever on a Sparc; same goes for any other
foreign machine like Alpha, MIPS, etc.... The attackers who had grabbed
the public exploits were all trying to use PC shellcodes, which could
crash the affected servers but wouldn't ever compromise them. So,
because the CPU couldn't run the code supplied by the attackers, it
stayed relatively safe in spite of the fact that it was horribly out of
date.

Now, I'm not suggesting that you put Linux on machines with non-x86 CPUs
and consider your security process completed. Different CPUs make the
cracker's job harder [2], but had any of the crackers wanted to get into
this machine, it should have been trivial.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Ask a Question
randomness