Architecture Diversity: A Security Perspective

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. They wanted to break into

*any* machine, not this one in particular. Since their scripts didn't

crack it, they didn't try to get into it manually. They'd doubtless have

better luck somewhere else anyway.

So my Sparc honeypot experience left me with one conclusion: Invest in

more floor space and put up a PC if I wanted to watch the bad guys in

action.

Or I could install Windows....

NOTES

[1] The only earthquake we noticed during our three year sentence in

California was a 5.2 about 30 miles away. Had we left a few weeks

earlier, we wouldn't even have had that one.

[2] I'll even argue with this comment myself. It's not harder to create

Sparc shell code, per se, it's just that more folks write their

exploits assuming an x86 processor. Thus the attacker must

write/borrow Sparc shell code to use instead. It's this extra level

of effort that most newbie crackers don't have, or don't bother

investing. Had they been determined, it would have taken another

half hour of research and testing to adjust their scripts to account

for alternate CPU types. The problem is that many attacks result in

only two possible outcomes: The attack is successful and they get

access, or the affected daemon crashes and they don't have a second

chance to try a different exploit.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies