Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Security Risks: A Look into the Future

By xL in Op-Ed
Fri Aug 08, 2003 at 11:10:28 PM EST
Tags: Security (all tags)
Security

Last month, a crazed call from a customer I was about to reel in with a hosting deal gave me another glance into the woeful state of internet security. A debian machine, acting as a proxy for some of his most important customer websites, had gone haywire. It refused to deliver mail and there was trouble getting in through ftp. A quick look over SSH confirmed a nasty suspicion: The machine had been compromised and run over by a rootkit. Although the break-in and installation of the rootkit had been done clumsily, the potential of deception that the software had, were it installed by an able person instead of a script kiddy, was chilling.


Rootkits are not a new trend. They have been around for most platforms since forever. What is new, though, is the lethal combination of an arrogant look on security issues from an ignorant majority of UN*X/BSD/Linux users and the emerging new near monoculture of Linux/x86. The Open Source marketing has made it a point that Open Source software offers better security than proprietary products.The point can certainly be made, but it is not always valid one.

Less enlightened administrators maybe got themselves a Linux server, put Apache on it and stuffed it in an abandoned corner just like the NT/IIS box they had before. The new Linux machine, however, is even much more a black box than the NT machine ever was. The NT machines crashed now and then. They needed new Service Packs to match the upgrades to the desktop machines. Probably the machine owners even bought a virus scanner to keep the machine clean. None of that's happening for the Linux box. It just keeps on running, so why bother feeding it?

This attitude towards technology is a new trend. As the industry and its products mature, people are more inclined to treat computing devices as black boxes. The whole appliance market capitalizes on this urge. The problem here is that most 'black boxes' are not quite as black as people hope. They do need software updates. GNU/Linux does have security problems that need updates. The sheer magnitude of this problem is generally overlooked.

There is a clone army of never updated Red Hat 5.2 machines out there in the big world, and you can trust the fact that 98% of them have since been cracked into by one or several script kiddies merrily using them for their IRC bots or DDoS drones. You can also be assured that these machines will remain to be 'owned' like that for averagely one year. These parasites are a problem that is currently hardly accounted for. Only on the shady world of IRC people get a glance of this emerging problem, where 15 year old pimplefaces with a collection of tarballs and perl scripts are able to warlord thousands of dollars of infrastructure damage at a whim.

On top of the black box problem, the PC architecture (like most architectures) is still far too dangerous to become as dominant as it is. Apart from OS security issues, there are several areas in the hardware architecture that pose serious security risks. One unexplored area of severe exploitation is PCI BIOS code executed on system boot. The dominance of certain classes of PCI card on intel-based server platforms is a likely vulnerability in that way. Although reflashing the system BIOS is usually restricted from hardware, there is very little stopping a privileged program from re-flashing an ATI graphics card, a Threeware IDE-RAID controller or a common Adaptec SCSI controller.

With hacked firmware installed on these cards, privileged code is allowed to run before the OS kernel gets any say. It is not unfeasible to abuse this principle to virtualize part of the other hardware, and thus control the machine at such a level that even a freshly installed OS kernel is fully unaware of the parasite code. No automatic package upgrades will rid the black box of its black hat.

With many networks heading this black box way, it becomes less and less obvious what any component's stated purpose and expected behavior is. The market for hosting and server colocation shows a very complex interaction between wholesale parties, a chain of resellers and end users, making physical access to many server locations easy to achieve. In-house server rooms are no less vulnerable. Like internet hosting, the telecommunications market is a confusing combination of enterprises, all of which generally have one or more points of interaction with a customer. There are so many parties with a legitimate need to get near a company's CAT5 spaghetti, that physical access cannot be seen as a deterrent against anything but random attacks. Unless if you have your servers in a vault, it is reasonable to assume that a determined enemy can and will have physical access to a network.

With physical access to a LAN, the amount of nastiness apart from creating outages or destroying data, can really be scary. Ethernet is an untrusted medium that has no cryptographic protection against inside tampering. A small device the size of a matchbox, stuck in the ceiling on a trunk line between two ethernet switches, could take ages to detect. It could disguise itself as any of the hosts that have traffic passing the wire. Existing patterns of external traffic could easily be used to hitch information outside the LAN undetected. Alternatively, it could introduce subtle errors in the traffic that would create a tremendous burden on the shoulders of the network administrators.

Now that the OS wars have become almost as irrelevant as the browser war and the platform wars, parasites of all kinds can become a big problem. We haven't cared about them so far, it is unreasonable to expect that we will in the near future. We are going to shove internet into more and more of our daily lives, though. And the more we do it, the more it will follow the black box paradigm. Which means the risks we are taking are getting bigger and bigger. Cyber-terrorism may have a silly ring to it now, but we'd better start worrying about it before the problem is real.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by xL


Display: Sort:
Security Risks: A Look into the Future | 166 comments (145 topical, 21 editorial, 0 hidden)
Monoculture of x86 (3.50 / 2) (#2)
by b1t r0t on Fri Aug 08, 2003 at 08:58:37 AM EST

That's why I only use two x86 boxes at home: one as a net gateway running Linux, and another (a W2K box which is never connected to the real internet) to play DivX. Everything else runs PowerPC. And I'd love to get OS X configured to replace the Linux box someday.

Apple is usually quick with security fixes, and the kiddiez can't afford to buy Macs anyhow, so they don't bother figuring out how to root them. That's fine with me.

-- Indymedia: the fanfiction.net of journalism.

you're living in dream land (none / 0) (#3)
by QuantumG on Fri Aug 08, 2003 at 09:08:11 AM EST

MacOS X is a Unix-like OS. Every kiddy knows how to root it. They don't bother most of the time because rooting servers is more useful, but if someone is pissing them off and they happen to be using a Mac, *bam*.

Gun fire is the sound of freedom.
[ Parent ]
Yes and no (4.00 / 1) (#4)
by xL on Fri Aug 08, 2003 at 09:15:29 AM EST

MacOS X is not invincible, for it is a Unix. But the fact is, most of the readily available compile-aim-and-fire exploits target Linux/x86, so the average script kiddy doesn't know where to start. I caught the rootkit on that debian machine because the dumb ass scriptkiddy had been unrolling a rootkit aimed at RedHat 6. His backdoored libc was incompatible in some areas. That's the average break-in for you. If they see OSX, they'll just throw every Slackware and Solaris exploit there is at it until they get bored and walk away to an easier target. That is not to say a determined, informed hacker could under no circumstances break into the Mac.

[ Parent ]
yeah, I don't know (3.00 / 1) (#5)
by QuantumG on Fri Aug 08, 2003 at 09:20:31 AM EST

Exploits are aimed at applications (unless they're really good) and MacOS-X runs just as many common open source applications as Linux (for example, Apache) and whereas those applications would be upgraded regularly on servers, I don't think your average MacOS-X user is going to be as dutious.

Gun fire is the sound of freedom.
[ Parent ]
Yes they are (5.00 / 2) (#6)
by xL on Fri Aug 08, 2003 at 09:24:19 AM EST

Which means code that can crash an application on one version of Unix, will also crash the application running on another. But to get something more useful out of the exploit than terminating a respawning server thread, you need to exploit the metrics of that crash to get the machine to execute code you supply with the privileges of the application you attack. This, in general, is x86 assembly code. Not PowerPC assembly code. That confuses the hell out of most scriptkiddies.

[ Parent ]
Agreed (none / 0) (#8)
by ph317 on Fri Aug 08, 2003 at 11:09:38 AM EST


Even though I'm a diehard linux/x86 fan, I use OpenBSD on an UltraSparc for my firewall/gateway box.  Even of any of the publicly available services on it have a remote root exploit identified for them, the OpenBSD/UltraSparc combo will through 99% of x86/win or x86/linux script kidz for a loop and at least slow them down and make them go for an easier target :)

[ Parent ]
Oops (none / 0) (#9)
by ph317 on Fri Aug 08, 2003 at 11:10:49 AM EST


Excuse my spelling, I just woke up :)

s/Even of/Even if/
s/combo will through/combo will throw/


[ Parent ]

openbsd on sparc or alpha is the MOST secure OS (4.00 / 1) (#85)
by treat on Sat Aug 09, 2003 at 10:38:43 AM EST

Even though I'm a diehard linux/x86 fan, I use OpenBSD on an UltraSparc for my firewall/gateway box.

Well, OpenBSD on the Sparc or Alpha is a lot more secure against buffer overflows than on the x86 thanks to hardware features. (the MMU allowing executable non-writable pages).

[ Parent ]

"for example, Apache" (3.00 / 1) (#11)
by truth versus death on Fri Aug 08, 2003 at 11:14:38 AM EST

Bad example. Mac OS X Server uses Software Update to update Apache automatically (of course you can configure this). Average Mac users would just use the built-in system-level web sharing (file sharing, etc) options, which are also updated regularly by the same mechanism. Average mac users don't need to be dutious. The OS takes care of it for them.

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
I rated you a 5, then realized (none / 0) (#13)
by porkchop_d_clown on Fri Aug 08, 2003 at 11:20:37 AM EST

that the exact same feature is available in most linux systems. My linux box runs up2date as a cron job....


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
erm (4.00 / 1) (#14)
by truth versus death on Fri Aug 08, 2003 at 12:14:15 PM EST

So? I wasn't making any comparison to Linux or any other operating system, just responding to QunatumG's beliefs about Mac OS X.

Does up2date get installed standard with your dist.? Is it already configured to do the checking for you on a regular basis?

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
up2date is part of RedHat's version (none / 0) (#43)
by porkchop_d_clown on Fri Aug 08, 2003 at 10:37:47 PM EST

And it is part of their hooks to try and get you to pay for what you use. Basically, it's set up so that you can use RH's web site to manage an entire group of Linux boxes.

Still, even the "demo" account gets the security alerts and automatically gets lists of updates. I got a warning about a problem just today; the patch will download ~ 4 am tomorrow morning.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
Should I return the rating favor? (none / 0) (#52)
by truth versus death on Sat Aug 09, 2003 at 01:29:34 AM EST

So there's some feature parity between Linux and Mac OS X, depending on which distro you download. This doesn't dampen the criticism of QuantumG's mistaken belief that average Mac OS X users aren't going to be dutious enough to upgrade regularly -- the OS does it for them! Maybe if you could explain why Linux having this capability renders my response inappropriate or unimportant to QuantumG's post, then I'd understand your downrating from your previous choice.

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
A 3 is an insult? (5.00 / 1) (#113)
by porkchop_d_clown on Sat Aug 09, 2003 at 08:51:18 PM EST

Actually I would have set it back to "none" (I generally don't like to down rate people) but for some reason, it won't let me. I can set it to any value from 1-5, but if I set it to none it doesn't stay. Dunno why.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
Yeah (none / 0) (#119)
by truth versus death on Sun Aug 10, 2003 at 12:10:58 AM EST

Messed up k5/Scoop thing. No worries.

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
Not necessarily an insult (none / 0) (#124)
by truth versus death on Sun Aug 10, 2003 at 05:34:40 AM EST

A 3 from a 5 is not necessarily an insult, but it means you thought the post had a certain amount of worth and then deigned it did not. Also, 3's work one's mojo down, instead of up, w.r.t. t.u. status.

The inability to go to none, as I read it, is to avoid people rating then unrating a comment without consequence -- mostly if someone rates 1's or 0's and then goes back on it to avoid getting in trouble for bombing. So, the basic rule is, once you rate, you're stuck rating, on that comment.

"any erection implies consent"-fae
[ Trim your Bush ]
[ Parent ]
Actually in Windows too (none / 0) (#96)
by Betcour on Sat Aug 09, 2003 at 04:55:00 PM EST

All the XP installs have Windows Update configured on automatic by default. I think this can be configured on automatic on older versions as well.

[ Parent ]
"for example, Apache" is a bad example (none / 0) (#122)
by TaoJones on Sun Aug 10, 2003 at 02:31:43 AM EST

Average mac users don't need to be dutious. The OS takes care of it for them.
Well that's pretty much the same point the article raises about Linux. Set it up, configure it "properly", and just ignore it. You'll be safe...

Technology is not a simple tool anymore. It is not a hammer which drives nails - it is an engine which requires at least a modicum of maintenance in order to function properly.

__

"Depression is just anger without enthusiasm. It's an empty beer bottle with no one worth throwing it at." Norma M.

[ Parent ]

A buffer overrun attack that works on X86 (none / 0) (#12)
by porkchop_d_clown on Fri Aug 08, 2003 at 11:19:12 AM EST

is guaranteed to fail on PPC.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
Buffer overflows and big/little-endian chips. (5.00 / 1) (#17)
by haflinger on Fri Aug 08, 2003 at 01:04:38 PM EST

I forget which is which. However, PPC is either big or little-endian, and x86 is the other way around. That means that buffer overflows (which are important to a lot of exploits, especially on *nix) work differently: the same bug is present, but its effect is different and the exploit needs to be rewritten somewhat. Most kiddies are not that skilled. ;)

Anybody with skills, however, it's not much of a challenge.

Did people from the future send George Carlin back in time to save rusty and K5? - leviramsey
[ Parent ]

Stacks that grow up or down (5.00 / 1) (#39)
by swr on Fri Aug 08, 2003 at 09:46:36 PM EST

Endianness doesn't really affect buffer overflows, beyond the difference in the CPU's instruction set. The exploit code must be executable by the CPU. x86 is little-endian, btw; most others are big-endian.

However, there is a difference between CPUs that grow the stack up versus those that grow the stack down. If I recall correctly, x86 grows down, which makes buffer overflow exploits easier because the overflow can overwrite the return address of the stack frame. On systems where the stack grows up, the overflow goes away from the return address, which makes exploiting things harder.

Simple buffer overflows ought to not be a problem with modern technology. If people would use a language that does bounds checking (Java, .NET managed, Perl, Python, etc) that particular type of vulnerability would be avoided. Heck, even just compiling the C/C++ with a stack protecting compiler would help (although I think heap overflows and more subtle stack overflows would still be a problem). Either way at least this frequently exploited type of vulnerability would go away or at least be reduced, and we could then turn our efforts to understanding and fixing (or exploiting, if that is your thing) more sophisticated bugs.



[ Parent ]
Sun has taken an interesting approach (3.00 / 2) (#41)
by omghax on Fri Aug 08, 2003 at 10:21:46 PM EST

with Solaris. (At least I think it's them.) Some time in... Solaris 9? they made their stack and heap segments flagged non-executable (or at least someone did -- in any case, it's a good idea long overdue and it should help alleviate problems). Also, Solaris has a pretty good working prototype of a security sandbox system to keep processes isolated from each other.

You're right about safety of languages that do bounds checking (and also conveniently lack true pointers), but buffer overflows are still the fault of programmers, not C itself. If we went back to the days where all programmers knew what they were doing we wouldn't have buffer overflows. =/

Incidentally, stack/heap growth is not fixed by the hardware architecture. On some systems it may be more feasible to implement it a certain way, but on any reasonably standard platform you can have a stack/heap that grows either up or down.


[ Parent ]

Ah the good old days (1.00 / 1) (#69)
by CwazyWabbit on Sat Aug 09, 2003 at 04:19:13 AM EST

Would you care to point out in which days "all programmers knew what they were doing" as I would have thought our problems these days are due to the connectivity of machines and not to a decline in programming skill.  When was that first internet worm again?
--
"But here's the thing: if people hand me ammunition, what kind of misanthrope would I be if I didn't use it?" - Sarah-Katherine
[ Parent ]
The Internet Worm was in the '80s. (5.00 / 1) (#78)
by haflinger on Sat Aug 09, 2003 at 07:12:29 AM EST

He's probably talking about the early seventies at the latest.

Did people from the future send George Carlin back in time to save rusty and K5? - leviramsey
[ Parent ]
Endianness (4.50 / 2) (#48)
by b1t r0t on Fri Aug 08, 2003 at 11:06:36 PM EST

There is a very small class of buffer overflows (one byte over, I think, perhaps caused by incorrect bounds checking) that only works on little-endian systems (such as x86).

Mostly it's just that the script kiddies are having enough fun with their x86 rootkits that they won't bother looking for PPC stuff unless they're targeting a specific host.

-- Indymedia: the fanfiction.net of journalism.
[ Parent ]

Mass reply to all my distractors (none / 0) (#42)
by QuantumG on Fri Aug 08, 2003 at 10:30:26 PM EST

Not every exploit uses a buffer overflow.. in-fact, in the case of Apache, most of them are not (for example, path manipulation). In any case, it is simply a matter of replacing one piece of shell code with another.. that's something even a script kiddie can do.. and it only needs to be done once and then traded a thousand times.

Gun fire is the sound of freedom.
[ Parent ]
And I have been rooted before (none / 0) (#44)
by b1t r0t on Fri Aug 08, 2003 at 10:42:56 PM EST

Both the current Linux box and one that has since been retired in favor of an old PPC running OS X got rooted back when the SSH exploit was popular. Two adjacent IP addresses, by different people a week apart. I don't know why someone didn't get both at the same time. Perhaps they were using random scanning.

But I haven't yet heard of _any_ OS X box getting rooted through a 'sploit. I'm not saying it can't happen. Just that the people with too much time on their hands don't want to bother, because of the low hanging fruit that is x86 Linux and Windows.

-- Indymedia: the fanfiction.net of journalism.
[ Parent ]

well said (3.25 / 3) (#10)
by VoxLobster on Fri Aug 08, 2003 at 11:12:40 AM EST

I'm tempted to hit the spam button just to help this into the queue faster, +1FP.

VoxLobster
I was raised by a cup of coffee! -- Homsar

There's nothing wrong with the x86 architecture NT (2.50 / 4) (#16)
by omghax on Fri Aug 08, 2003 at 12:50:05 PM EST



Yes there is (3.00 / 2) (#24)
by kphrak on Fri Aug 08, 2003 at 04:57:04 PM EST

It's CISC. Have you ever tried coding in assembler for an x86 chip? The...pain...


Describe yourself in your sig!
American computer programmer, living in Portland, OR.


[ Parent ]
Assembler is usually more fun on CISC (5.00 / 1) (#34)
by zakalwe on Fri Aug 08, 2003 at 06:33:01 PM EST

CISC is usually much nicer to manually code in assembler than RISC (Thats the whole point really - let the compiler handle the fiddly details) x86 is just horribly ugly and packed full of legacy crap.

[ Parent ]
80386 assembly is amazingly fun (4.66 / 3) (#40)
by omghax on Fri Aug 08, 2003 at 10:07:19 PM EST

There are, I think, 17 different MOV instructions or some such. There are four different levels of privilege, you've got full-fledged protected mode, interesting options for segmentation/memory management due to intelligent chip design... x86 gives you a lot to work with.

It's not filled with "legacy crap". Most systems today use PCI (developed by Intel, by the way), which is pretty much the de facto standard. 8086 emulation might be considered "legacy crap", but most people don't use it and it doesn't impact system performance. And, when the chip was introduced, it made sense, since a lot of old DOS programs weren't rewritten for the newer chips yet. Especially the 80286, with its horribly flawed protected mode design.

Notice how many other platforms are massively incompatible between different lines of kit running the same processors with the same instruction sets, architecture, etc. x86 has to be the most standardized architecture in the world, due in large part to the things most people find "ugly", such as the Intel BIOS (which has no true counterpart anywhere else) and interrupt system, and so forth.

It doesn't have lots of registers or register windows, like the Alpha and SPARC, respectively, but it was the first to realistically address (or at least help alleviate) this problem with DMA. It doesn't scale well, but it wasn't designed to, so one can't really complain.

Sorry about the rant, but I really love the Intel architecture (even though I am a UNIX fan and adore Alpha and UltraSPARC too) and it makes me sad when people bash it. =/

[ Parent ]

Most legacy instructions (1.00 / 1) (#73)
by schlouse on Sat Aug 09, 2003 at 05:02:27 AM EST

I believe that most of the rarer instructions are implemented in microcode, which helps keep everything more trim (did I really just say that :-). They're supposedly a bit slower, but still faster than coding up something with multiple instructions.

For example, I recently needed to scan a bitfield for the first bit set. The ASM produced for non-x86 processors was not optimizable (by me at least :-), but the x86 has bsf & bsr (bit scan forward/reverse). Just what I was looking for. Ran about 50x faster, too.

Mark S.

[ Parent ]

Uh. (3.00 / 1) (#91)
by awgsilyari on Sat Aug 09, 2003 at 12:53:52 PM EST

For example, I recently needed to scan a bitfield for the first bit set. The ASM produced for non-x86 processors was not optimizable

Jesus, have you no creativity at all? How wide is this bitfield? If it's a reasonable size like 8 or 10 bits, then just make a lookup table that maps bit patterns to the index of their first bits.

int first_bit_index[256] = {-1, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 4, ... }

Now to figure out the index of the first bit turned on, just say first_bit_index[bit_pattern] -- a single memory lookup == single instruction.

You can use the same technique for wider bitfields at a slightly higher cost:

if(bit_pattern > 255) // we know the high bit must be in the high byte
    first_bit = first_bit_index[bit_pattern >> 8] + 8;

And you call yourself an ASM coder. :-P

--------
Please direct SPAM to john@neuralnw.com
[ Parent ]

Well (1.00 / 1) (#115)
by schlouse on Sat Aug 09, 2003 at 09:37:24 PM EST

The bitfields are usually several thousand bits wide, of course addressable by 32 bit words. Your scheme does not work too well when going there. There are several other schemes, like binary search to determine the byte, then using a byte lookup table, which is in fact what you're doing in your example.

Now also understand that if you order the memory accesses so that they go upwards, you also get the hardware prefetch mechanism going, so that by the time you're done with the current cache line, the next is most likely already there for you.

Simply put, the convenience and speed of the bsr/f instructions matches perfectly for this application, and directly translates to a greatly increased lookup speed.

Mark S.

[ Parent ]

Blech (5.00 / 1) (#128)
by Bad Harmony on Sun Aug 10, 2003 at 08:28:15 AM EST

A real programmer would also know that, on many systems, the cache misses triggered by the use of a lookup table would kill system performance.

5440' or Fight!
[ Parent ]

s/would/could [nt] (none / 0) (#132)
by schlouse on Sun Aug 10, 2003 at 07:00:56 PM EST



[ Parent ]
Urm (none / 0) (#151)
by awgsilyari on Mon Aug 11, 2003 at 12:35:08 PM EST

If a 256-byte lookup table is big enough to fill the cache of whatever weird chip you're referring to, then I'd say you have bigger problems than whether there is a BSR instruction...

--------
Please direct SPAM to john@neuralnw.com
[ Parent ]
Gak (none / 0) (#155)
by Bad Harmony on Mon Aug 11, 2003 at 05:24:22 PM EST

It depends on the table size, cache size, cache associativity, how often the table lookups are done, what other code is running, etc.

On old systems, or on microcontrollers, table lookups can be a great help. Memory access times are predictable and short compared to CPU cycle times.

Where you can get killed is on newer systems where there is a huge penalty for cache misses. Inline code can be surprisingly fast if the processor is prefetching the code into the cache.

I've seen this problem on benchmarks of time-critical code. Optimizations that worked great on old systems no longer work as well or actually make things worse.

The processor's architecture can be important. I've written code that ran great on Intel processors but turned an Alpha into a slow POS.

5440' or Fight!
[ Parent ]

Quite true (none / 0) (#162)
by ZorbaTHut on Tue Aug 12, 2003 at 11:52:09 PM EST

void strcpy( char *a, const char *b ) { while( *a++ = *b++ ); };

That actually outperforms MSVC++6's strcpy on P2s and above, but MSVC++6's is better on Pentium 1's and below.

(I don't know whether they fixed it for MSVC.NET.)

[ Parent ]

Open Firmware (none / 0) (#129)
by komadori on Sun Aug 10, 2003 at 01:24:12 PM EST

The only manner in which the IBM-PC BIOS has no true counterpart is that no other platform has standardised on such an unmitigated pile of crap. Open Firmware (IEEE 1275) is far superior.

"When we are victorious on a world scale I think we shall use gold for the purpose of building public lavatories in the streets of some of the largest cities of the world." Vladimir Illich Lenin


[ Parent ]
Open Firmware is broken (none / 0) (#136)
by omghax on Sun Aug 10, 2003 at 09:57:57 PM EST

It's horribly inconsistent between different architectures or even different machines running the same architecture. It attempts to provide far more functionality and abstraction than is (in my experience) healthy and it's nothing near "standard".

The PC-BIOS performs all the functions it was designed to more than adequately. More than that, it's standard between architectures. It does have some limitations but these can be overcome easily and in a manner that is portable across all x86 machines.

[ Parent ]

Re: Open Firmware is broken (none / 0) (#148)
by komadori on Mon Aug 11, 2003 at 07:34:34 AM EST

How can the IBM-PC BIOS be standard between architectures when it only supports one architecture? The portability of system software across different IBM-PC compatibles is only becuase IBM-PC compatibility requires the same superset of the orginal 8086 privileged architecture and the same superset of the original IBM-PC peripherals to be implemented on all machines.

Open Firmware is by no means perfect, but it provides a rich array of services to the both the user and the operating system which leave IBM-PC BIOS implementaions (PXE included) in the dust.

"When we are victorious on a world scale I think we shall use gold for the purpose of building public lavatories in the streets of some of the largest cities of the world." Vladimir Illich Lenin


[ Parent ]
I didn't mean microprocessor architectures (none / 0) (#154)
by omghax on Mon Aug 11, 2003 at 05:11:04 PM EST

Look at how many Open Firmware incompatabilities there are between different machines running the same microprocessor.

Again, you think the features provided by Open Firmware make it superior to the BIOS. I prefer something that isn't buggy: functionality provided by Open Firmware on some platforms can be easily replaced with custom software on the x86.

[ Parent ]

Nothing wrong? (5.00 / 2) (#46)
by porkchop_d_clown on Fri Aug 08, 2003 at 11:02:23 PM EST

Other than being a 30 year old design, I'd agree with you.

The modern P4 system is like a young kid being forced to tow his father, his grandfather, his great-grandfather, his great-great-grandfather, his great-great-great-grandfather, some schmuck named Sir Doink of York and a caveman named Ogg.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
and this relates to security how? [n/t] (none / 0) (#50)
by QuantumG on Sat Aug 09, 2003 at 12:47:27 AM EST



Gun fire is the sound of freedom.
[ Parent ]
You are like many others misinformed (3.00 / 1) (#94)
by omghax on Sat Aug 09, 2003 at 04:14:45 PM EST

While it is true that the architecture is and always has been forced to deal with earlier versions of itself, this doesn't have any real impact on performance or usability or anything else that matters.

It just bugs some obsessive-compulsive nuts because they like pure architectures.

[ Parent ]

Electricity and cooling (none / 0) (#118)
by pin0cchio on Sat Aug 09, 2003 at 11:15:07 PM EST

While it is true that the architecture is and always has been forced to deal with earlier versions of itself, this doesn't have any real impact on performance

False. The x86 decoder covers a significant portion of the die size of modern x86 processors. If the decoder could be made simpler (as in PowerPC, SPARC, ARM, MIPS, etc), it could be made smaller, and in turn the total die size would be smaller (increasing yield), and it wouldn't take as much electricity or require as much cooling. This in turn makes blade clustering quite a bit more practical, reducing costs.


lj65
[ Parent ]
True, but (none / 0) (#134)
by omghax on Sun Aug 10, 2003 at 09:51:10 PM EST

The x86 isn't designed for scaling and it isn't intended to scale. The complexity of the decoder is what gives the architecture its flexibility.

[ Parent ]
Misinformed? (5.00 / 1) (#138)
by porkchop_d_clown on Sun Aug 10, 2003 at 11:06:20 PM EST

What, simply because I lived thru and coded for every generation of x86 since the 8086?

yup. Clearly that has left me ignorant of the strengths and weaknesses of the PC architecture say, compared to every other hardware platform that has come and gone in that time frame.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
Inflammatory but without substance NT (none / 0) (#139)
by omghax on Mon Aug 11, 2003 at 12:16:41 AM EST



[ Parent ]
Executable stack (none / 0) (#74)
by Tau on Sat Aug 09, 2003 at 05:04:01 AM EST

IA32 doesn't distinguish between read and execute access in its pagetables. Other architectures do and that lets you nip the whole stack overflow shellcode problem in the bud. I recall there was recently some sort of stackguard patch for Linux that mitigated this somewhat but that attacks the problem at entirely the wrong level.

The other problems are the huge amount of legacy crap and special cases in the instruction set architecture itself that makes for enormous chip dies (I'm not processor design expert but I imagine that making an efficient pipelining engine for five generations of CPU at once is one of the more acute, although well-paying forms of masochism known to man) which will in turn seriously limit the PC architecture in the future. Incidentally this is why I'm so against AMD's x86-64 architecture. Want a 16+32+64bit architecture, all completely entangled? IA64 is at least totally separate from IA32 which lets you jetisson the old crap eventually, pity Intel had to fuck it all up.

Anyway I digress.

---
WHEN THE REVOLUTION COMES WE WILL MAKE SAUSAGES OUT OF YOUR FUCKING ENTRAILS - TRASG0
[ Parent ]

Hmm (none / 0) (#93)
by omghax on Sat Aug 09, 2003 at 04:11:23 PM EST

While your first point has some merit, you can still have non-executable segments, it just takes a marginal amount of extra work on the part of the operating system. It's by no means unfeasible or even difficult.

Your others are misinformed/aesthetic. Large chip dies have little to do with anything unless you're intending to cluster chips to make servers, and the x86 wasn't designed and isn't intended to scale to any significant degree.

And I'm a big fan of the versatility of the x86, and that versatility comes from the "legacy crap" and "special cases" that you loathe.

Instead of nitpicking, I wish people would just recognize the x86 for what it is: a brilliantly-designed architecture that solved many of the pressing microprocessor issues of its time and that has continued to evolve and adapt and be useful.

[ Parent ]

Really (none / 0) (#125)
by Tau on Sun Aug 10, 2003 at 07:44:30 AM EST

This is partially right yes. A 386 is indeed a very small, powerful and flexible piece of kit; that it can do simple 16 bit paged stuff as well as two different styles of memory management in a 32 bit mode as well as some specially optimised CISC stuff can be quite useful. For embedded applications. I believe they're still used a fair bit in that capacity. What I don't see is what all that flexibility is good for on a desktop. Because you really don't need all that extra crap on your average desktop. You need paged memory without all this protection ring and segmentation stuff, you'll probably want a floating point unit and some decent integer instructions as well as a buttload of registers, and it can be either CISC or RISC; RISC seems to be going out of fashion these days but the instruction set doesn't need all this ancient stuff and that's because the 386 comes from an age where size and efficiency was everything.

These days, for better or for worse, things have to be simple and scaleable; efficiency doesn't count for jack because in the time it takes you to design some efficient corner-case instrcutions and then get all the compilers to use them and applications to be compiled under them you can bang on an extra 2GHz in the implementation with no worries.

Except for the worry of increasingly concurrent execution cores requiring a massive decode+schedule+pipeline+branchpredict unit that's spiralling out of control thanks to all this flexibility of yours. One wonders why non-x86 architectures haven't overtaken Intel yet. Massive market dominance probably...

---
WHEN THE REVOLUTION COMES WE WILL MAKE SAUSAGES OUT OF YOUR FUCKING ENTRAILS - TRASG0
[ Parent ]

You're criticising the x86 (none / 0) (#135)
by omghax on Sun Aug 10, 2003 at 09:54:06 PM EST

for its failure to be something that it was never intended to be and is not designed to be. This is exactly why Intel has decided to break compatability in favor of a completely new IA64, which is designed to meet an entirely different set of goals and overcome an entirely new set of problems.

[ Parent ]
And I wish them well. (none / 0) (#160)
by Tau on Tue Aug 12, 2003 at 07:25:40 AM EST

Problem is it looks like this problem is only going to be compounded by AMD's 64 bit arch, which looks quite clearly dominant at present.

---
WHEN THE REVOLUTION COMES WE WILL MAKE SAUSAGES OUT OF YOUR FUCKING ENTRAILS - TRASG0
[ Parent ]
x86 evolution (none / 0) (#97)
by Betcour on Sat Aug 09, 2003 at 05:10:30 PM EST

The other problems are the huge amount of legacy crap and special cases in the instruction set architecture itself that makes for enormous chip dies

From what I understand modern x86 processors don't bother implementing all the legacy instructions, they are really RISC-like chips with a decoder part that translate complex CISC instructions stuff into several simple instructions that the core understand. I don't think those decoders take up any noticable die-size (especially compared to the massive L2 caches you can find now)

[ Parent ]
Decoders are big (none / 0) (#117)
by pin0cchio on Sat Aug 09, 2003 at 11:11:06 PM EST

[modern x86 compatible processors] are really RISC-like chips with a decoder part that translate complex CISC instructions stuff into several simple instructions

True. This is how every x86 since at least the Pentium Pro has operated. But...

I don't think those decoders take up any noticable die-size

On many processors (especially the P4 and possibly the Athlon), about half of what isn't L2 cache is the x86 decoder.


lj65
[ Parent ]
Why am I the only one who doesn't find this... (4.87 / 8) (#36)
by zipper on Fri Aug 08, 2003 at 07:27:22 PM EST

... particularly insightful?

For starters, how can you call this "A Look into the Future" when you first point is about the (supposed) abundance of ancient machines? The problem isn't with the ancient machines, because (by and large) they were rooted years ago, when they were new. Machines that were rooted via statd and wuftpd eventually get patched (either by attackers or admins), and slowly drop out of circulation. Unsurprisingly, the biggest threat is with NEW vulnerabilities on newer, more prevalent OS versions. BIND got a lot of attention. OpenSSH got a lot of attention. Apache got a lot of attention.

The majority of DDoS machines aren't even running *ix variations, they're running windows. While a single *ix machine is far more likely to be sitting on significant bandwidth, it's a lot easier to mass up hundreds or thousands of Windows machines. The bandwidth of the individual machine is less, but the aggregate bandwidth is much more, making it more effective.

Your comments about blackboxes remind me of the much-mocked article on Securityfocus about *evil hackers* using dreamcasts running linux to hack networks from the inside... because who wouldn't think a dreamcast plugged into the wall didn't belong there?

I disagree with you completely on the issue of physical security. A proper security plan should have any visitor to a facility *escorted* at all times by staff. I realize this is "inconvenient", but that's what it takes to make it secure. Make sure that you don't string your cat5 all over the place too. I found out recently that our cat5 travelled out over an open hallway with ceiling tiles. Needless to say I had it removed. With planning and a security guide that gets followed, it's a non-issue.

Aside from your theories on flashing pci roms (where applicable) there's really nothing new here.

---
This account has been neutered by rusty and can no longer rate or post comments. Way to go fearless leader!
I cannot influence your enjoyment (5.00 / 1) (#56)
by xL on Sat Aug 09, 2003 at 03:00:42 AM EST

But perhaps you are looking for the wrong things. I see many initial responses from people who somehow feel the situations sketched necessarily apply to their perfectly installed machines or perfectly secured hosting facilities. My point is not that security is impossible, it is that many people do not care to achieve it and this number is rising. The pool of 'abandoned' network appliances is growing over time and it is becoming more and more homogenous.

[ Parent ]
The article raises a significant point. (3.00 / 2) (#71)
by schlouse on Sat Aug 09, 2003 at 04:29:54 AM EST

The discussion generated about malicious code flashing BIOS's is a significant point. Many modern machines use standard flash parts. Think about the economic damage to a company caused by the following scenario:

1. A remote IIS bug is discovered in private.

2. An attacker writes exploit code that corrupts the entire flash part of a popular line of servers, including the boot block recovery code, used by some modern servers.

3. The attacker uses this on about 10 thousand sites before the bug is disclosed publically.

Companies like Compaq and Dell are vulnerable to this. The only thing that really prevents it is the difficulty of it. If a well funded organization or hostile foreign government funded such an attack, it may be viable.

Not only would the sites in question be shut down, but they would have to physically send their server back to the manufacturer. This could cause significant economic damage to the manufacturer.

Mark S.

[ Parent ]

I would mock this (4.50 / 4) (#37)
by regeya on Fri Aug 08, 2003 at 08:16:13 PM EST

However, I have a boss who gets mad if I stay over to install security updates.

"Why are you here? Wasn't that working fine before?"

Lord help me if the security update breaks anything...


[ yokelpunk | kuro5hin diary ]

Re-flashing (5.00 / 1) (#38)
by vadim on Fri Aug 08, 2003 at 09:16:36 PM EST

I don't know if such a thing would be good for anything. First, a server will probably not have much to flash on a video card, since why would it need 3D support? 2D was figured out a *long* time ago and I can't think of any card where it could be updated.

Besides, supposing a component was flashed, how would it create an exploit? Current OSes like say, Linux, don't use the BIOS at all. One the computer boots the BIOS shouldn't get any kind of control. That'd leave potential explots to things like patching boot sectors, which are really nothing new. Sure you can leave the machine unbootable, but that is hardly a good idea. You'd give the victim very good ammunition to sue you for damages.

So seems we're left with firmware. That's if there's anything flashable on the board. Other than the BIOS I doubt anything can be flashed on my motherboard. Even if there is something that could be, why would anybody bother with it? If you can flash stuff then you're root already. And if you're root you can already mess with whatever you want. A rootkit is also much easier to install than a patch to the firmware of some specific chip
--
<@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.

You'd be surprised. (5.00 / 3) (#45)
by porkchop_d_clown on Fri Aug 08, 2003 at 10:56:17 PM EST

Lots of things have flash ROM that you wouldn't expect. Hand held devices, bottom-of-the-line routers (if 2d is all figured out, how hard can it be to make a simple router?). It absolutely would not surprise me to hear that a particular NIC has flash ROM.

As for linux not using the bios - that's trivially false. Of course linux uses the video card bios. Do you really think every driver writer wants to re-code the "draw a horizontal line" method?

The whole point of a bios exploit is that it can be installed below the OS. If I can put a trojan in your NIC, you are SOL. I can open ports and tell you they are closed, and DMA straight into and out of main memory.


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
Things with BIOSes (5.00 / 3) (#49)
by ZorbaTHut on Fri Aug 08, 2003 at 11:32:49 PM EST

A while back, out of curiosity, I went through and tried to figure out just how many flashable BIOSes I could find on my system. Final list:

Motherboard
Video card (high-end 3d card)
SCSI card
CD-RW
Hard drive
NIC
Modem
Sound card

I think this is basically all the parts of the computer except the floppy drive, the RAM, the CPU, and the PSU :P

For the very curious, in detail:

Motherboard is obvious. We've all updated *that* one. Video card I'm pretty sure about because it displays a serial number on startup that changes when I update it. SCSI card I'm very sure about since I've explicitly updated it. My CD-RW drive had a "download firmware" option, and it would indeed reprogram the CD-RW (or at least, certainly act like it), then tell me to reboot. My hard drive I have not actually updated - however, it's the same model I have at work, and we *did* update the ones at work due to a problem with our RAID card. (Which has a BIOS of its own, of course.) I vaguely remember updating the firmware on my NIC, but I could be misremembering that one. I *know* my modem had a "pay $30 to remotely upgrade to 56k mode", and that sounds like firmware to me. (I can't remember why I had the modem in at that point.) My sound card I'm actually the least certain about - they released new drivers with very impressive major changes, but I suppose it could just be some odd system where the Windows driver sends it a program to run in local RAM every time it boots up.

In summary: It has a flashable BIOS. I don't care what it is, but it's almost certainly flashable.

Keep in mind that a BIOS exploit doesn't have to be even remotely large - all you need to do is have it intercept LILO and change where it's looking for the kernel. Now you have the ability to load a custom kernel. Now your target is screwed.

[ Parent ]

obPSU (4.00 / 1) (#59)
by xL on Sat Aug 09, 2003 at 03:18:05 AM EST

The SGI Origin servers have a PSU with an RS-422 serial interface on it. I was really amused to find out that, yes, you could get a console on the machine's power supply. I just figured getting new firmware on a PSU could be useful too. You could use timed powerflips to communicate binary data to the outside world. Some people might notice, though, that the server is rebooting itself like a fevered monkey.

[ Parent ]
obCPU (5.00 / 1) (#65)
by swr on Sat Aug 09, 2003 at 04:08:49 AM EST

I think this is basically all the parts of the computer except the floppy drive, the RAM, the CPU, and the PSU :P

Your CPU may not have its own BIOS, but it probably has software-reprogrammable microcode. Probably requires flashing the system BIOS to change though; I expect the reprogrammability would be disabled after initialization.



[ Parent ]
Hrm.... (none / 0) (#53)
by edward on Sat Aug 09, 2003 at 01:48:44 AM EST

Well, you might be able to DMA into memory but even then you've got to get the right spot in memory for the machine to execute the code, without overwriting a critical part of memory when you do the DMA. That's actually pretty hard. Non-executable stacks squish that weakness.

With respect to telling the OS that a port is closed when in fact it's open-- remember that the NIC is passing ethernet frames to the driver -- TCP/IP ports don't really exist, as far as the NIC is concerned. Anyway, even if I'm wrong on that, any half-idiot who claims to have anything to do with security at all would nmap her box from the external interface before putting it into production, thus noticing a discrepancy between what's being reported on the interface and what is being reported by netstat.

Heh, it's the device driver that talks to the video card BIOS, and it's a very lowlevel, simplistic sort of conversation. If you expect any kind of code in the video card BIOS to be able to make the OS do weird things, the weakness has to be in the driver too.

[ Parent ]
You are missing the point (none / 0) (#64)
by schlouse on Sat Aug 09, 2003 at 04:08:19 AM EST

Well, you might be able to DMA into memory but even then you've got to get the right spot in memory for the machine to execute the code, without overwriting a critical part of memory when you do the DMA. That's actually pretty hard. Non-executable stacks squish that weakness.
The suggestion isn't to coerce the device itself into DMAing malicious code over part of memory. That would probably require modification of the device's microcode, and most devices don't have that capability. Non-executable stacks really don't have anything to do with it; the DMA could easily overwite any data in any page marked as writable by the MMU.
Heh, it's the device driver that talks to the video card BIOS, and it's a very lowlevel, simplistic sort of conversation. If you expect any kind of code in the video card BIOS to be able to make the OS do weird things, the weakness has to be in the driver too.
The video card BIOS almost exclusively just initializes the device and sets it up for use by the system BIOS runtime. You are absolutely right about the driver part though; really all weirdness must be in the driver.

The main point of the original poster was that the video BIOS entry point be used as a hook point to execute malicious code, not to modify the BIOS itself to affect a higher layer.

Mark S.

[ Parent ]

Is this a troll or what?. I'll bite. (none / 0) (#81)
by edward on Sat Aug 09, 2003 at 09:29:01 AM EST

The suggestion isn't to coerce the device itself into DMAing malicious code over part of memory. That would probably require modification of the device's microcode, and most devices don't have that capability.

Huh? Programmable microcode is what we're talking about here. It's a flashable BIOS, right?

Non-executable stacks really don't have anything to do with it; the DMA could easily overwite any data in any page marked as writable by the MMU.

What? Of course the DMA could easily write to any page marked writable by the MMU that's what it freakin' does.But so what? All this would do is fill up memory. If the code doesn't get executed, it's not that dangerous. Thus, the code must get written somewhere in memory that the CPU is going to fetch an instruction from. Writing to RAM when a computer boots up isn't that fruitful, because the computer isn't going to be looking at RAM for instructions until it's started to read the boot sector from the disk. In whatever tiny slice of EEPROM you have to work with on your video card, getting anything there that affects the bootup process in a meaninful way is almost impossible.

The video card BIOS almost exclusively just initializes the device and sets it up for use by the system BIOS runtime. You are absolutely right about the driver part though; really all weirdness must be in the driver.

Yes, I am right. Thank you.

The main point of the original poster was that the video BIOS entry point be used as a hook point to execute malicious code, not to modify the BIOS itself to affect a higher layer.

Yes, and my point was that that particular premise in the parent is false. Video card BIOSes aren't an issue. I'll still admit that there is a greater issue with system BIOSes, but even then, you know those little things called jumpers? Well, you really should be buying motherboards that have a system BIOS programmable jumper that, when open, prevents the BIOS from being flashed. Oh, and you know that little 'Virus Warning' in your BIOS's setup menu? That will also alert you when something is trying to overwrite you BIOS (or MBR). Oh, and you've heard of those fancy high-end motherboards that include two copies of the BIOS onboard, so that if one gets damaged, the fail-safe is still there?

Look, the bottom line is that getting BIOS code to do something more nasty than a Denial-of-Service kind of attack is extremely difficult. That it is a major threat to system security is not true-- it may be a threat, but an eclectic and minor one to be sure.

[ Parent ]
Scratch that... (4.66 / 3) (#83)
by edward on Sat Aug 09, 2003 at 10:00:54 AM EST

You are correct, I am wrong. This post was garbage.

[ Parent ]
They get loaded before the kernel (5.00 / 2) (#47)
by QuantumG on Fri Aug 08, 2003 at 11:02:58 PM EST

therefore they can do anything. As long as it still results in the kernel being loaded, the administrator/user will be unaware. The code could do something as simple as patching the kernel to ignore non-uid-0 privledged operations requests.

Gun fire is the sound of freedom.
[ Parent ]
Reflashing cards (none / 0) (#55)
by Ta bu shi da yu on Sat Aug 09, 2003 at 02:41:59 AM EST

To reflash a card, you'd have to be able to get into the box first. So... wouldn't they have to have found an exploit to run code that has a high enough privilege level in the first place?

Just a thought.

Yours humbly,
Ta bù shì dà yú

---
AdTIה"the think tank that didn't".
ה
[ Parent ]

root = game over? (5.00 / 5) (#62)
by swr on Sat Aug 09, 2003 at 03:55:29 AM EST

Right. The intruder has to have full access to the box to do such things.

When discussing security, it's often said that "once an intruder has root/admin, it's game over" (or words to that effect). For the admin it is; he has to nuke the system when he notices the compromise. But for the intruder it's just the beginning. He has access to the box, and probably wants to keep it.

It is generally assumed that reinstalling all of the software from trusted media is sufficient for the admin to get the machine back up. If "firmware rootkits" start showing up in the wild then that will no longer be a safe assumption.



[ Parent ]
Good point. (nt) (none / 0) (#66)
by Ta bu shi da yu on Sat Aug 09, 2003 at 04:13:31 AM EST



---
AdTIה"the think tank that didn't".
ה
[ Parent ]
Have you ever looked (none / 0) (#58)
by xL on Sat Aug 09, 2003 at 03:14:16 AM EST

at your screen when you start up the PC? Many cards happily flash their PCI BIOS identification text on your screen before you ever get to the bootloader. From there, you are home free. Your kernel may think it is controlling the machine, but it's really talking to the parasite code. Sort of like vmware.

[ Parent ]
Unfortunately (none / 0) (#61)
by schlouse on Sat Aug 09, 2003 at 03:49:44 AM EST

Unfortunately, the BIOS is usually only used for proper initialization, or to upload microcode to the particular device. Only in situations where you're using an OS that uses BIOS calls (MSDOS or a hobby OS... slow, slow, slow) would your suggestion work. All modern OS's will provide a real driver for the device, and bypass any BIOS code, which would require a processor mode switch to real mode to use (again, slow).

Mark S.

[ Parent ]

Sheez, am I so unclear? (none / 0) (#63)
by xL on Sat Aug 09, 2003 at 04:01:54 AM EST

The kernel does not have to do jack with the newly flashed BIOS. The code is executed on PC startup. Not by the kernel. By the PC.

[ Parent ]
Yes (none / 0) (#67)
by schlouse on Sat Aug 09, 2003 at 04:14:26 AM EST

Originally you said:
Your kernel may think it is controlling the machine, but it's really talking to the parasite code. Sort of like vmware.
Unless you were suggesting patching the OS from the BIOS (which you made no mention of), I thought that you were suggesting that the kernel talks to the BIOS to control the system. That's not correct, but perhaps I didn't understand you correctly.

The BIOS really just exists to allow a modern OS to bootstrap. The OS then loads protected mode drivers for each system device.

Mark S.

[ Parent ]

I was thinking more along the lines (none / 0) (#70)
by xL on Sat Aug 09, 2003 at 04:23:04 AM EST

of taking over ring0 and defer some useful interrupts to the parasite code. Virtualize the machine so you can screw around with the real machine without the OS ever knowing any better.

[ Parent ]
That is certainly possible (none / 0) (#72)
by schlouse on Sat Aug 09, 2003 at 04:37:24 AM EST

However, it would require a significant footprint on disk, probably more than could be hidden successfully in a place that would not be normally overwritten (see my other comment in this thread). In that case, why bother with the BIOS modification at all, and simply use a garden variety MBR or bootsector virus to accomplish this?

Mark S.

[ Parent ]

I tend to think your idea makes more sense (none / 0) (#75)
by xL on Sat Aug 09, 2003 at 05:11:43 AM EST

But with it being necessarily written towards a specific OS kernel family, it's bound to be less prolific. It's much easier to achieve, though, so much more likely to happen.

[ Parent ]
An example exploit (5.00 / 2) (#60)
by schlouse on Sat Aug 09, 2003 at 03:40:19 AM EST

Typically when a BIOS boots, the BIOS runtime is decompressed into RAM before any of the option ROM's are executed. The runtime is the layer that provides many of the services used by bootloaders and things like MSDOS, for example (why do you think MSDOS loads on your new P4 without any special drivers? The BIOS runtime abstracts enough of the hardware for basic, albiet slow, functionality). If you have ever programmed in assembly for DOS, you will probably be familiar with Ralph Brown's interrupt list which a good source for information on what the BIOS runtime provides.

As an option ROM programmer, this means that you can use just about any of the BIOS runtime to do your bidding, in unfettered assembly before any OS loads. The interesting thing here is that you also have access to disk routines, not just display routines. This may have been fine back in the day when everything was on ROMs, but in this day and age of EEPROMs, just about everything is updateable via software. Most are supplied via standard parts that have a readily available datasheet. Many update programs run under DOS, so the exact functioning of the update mechanism can be disassembled without too much trouble.

Those of you that have done your homework may already know how MBR's work. Those of you that have been around awhile also probably know how the famous int 13 hooks worked as well. Those of you that are real nerds may know that partitions nearly always start on certain boundaries, leaving plenty of room between the MBR and the first partition's boot sector. Some early disk compression programs actually took advantage of this space. Also note that partitioning programs and formatting utilities do not overwrite this area!

A nasty program could:

1. Begin as a remote root exploit of some kind, and carry as a payload code that identifies common hardware that has option ROM's updateable via software.

2. Write self-decompressing OS patching code to the disk sectors between the MBR and first partition.

3. Modify the EEPROM's such that the functionality is preserved, but insert malicious code. This code checks if the disk sectors in #2 are installed, and if so, loads and executes them. This extra code in the EEPROM would have a pretty small footprint and should fit on most devices just fine.

At boot, the option ROM would effectively patch the OS. The control would return to the BIOS, and the BIOS would load the patched OS. The large amount of space afforded in the spare disk sectors would probably allow a complex and diverse set of operating systems to be patched at boot.

Due to the fact that most partitioning programs do not mess with sectors they do not own, this kind of thing can sit there forever and never get overwritten, even though the owner of the machine may have reinstalled several different OS's several times! An alternative approach may be to hide the data in supposed bad sectors, if possible, or use spare sectors at the extreme end of the disk.

Mark S.

[ Parent ]

Well... (none / 0) (#84)
by edward on Sat Aug 09, 2003 at 10:05:41 AM EST

While steps two and three are possible, it's going to be harder and harder to make step one work. The bottom line is that remote root exploits are being slowly wiped away from how computers interact with their networks. It's a design flaw that a process has root privileges and sits on the network. This problem will slowly go away, because it is not the right way to do things. The bottom line is that it's going to get harder and harder to execute code with superuser privileges across the board, on any OS.

[ Parent ]
What metrics? (none / 0) (#88)
by xL on Sat Aug 09, 2003 at 11:24:33 AM EST

Not many daemons interact directly at a root level, and there's only so much you can screw up in a kernel's packet handling, granted. Generally root on systems these days in obtained by a combination of an exploit to get command access as user nobody/http and a local exploit to elevate privileges to root. Directly rootable daemons may be mostly history, but internet daemon exploits as well as local privilege exploits are not going to disappear suddenly.

[ Parent ]
Good point. (none / 0) (#90)
by edward on Sat Aug 09, 2003 at 11:48:22 AM EST

But I think that even local exploits will become rarer and rarer. At least, buffer overflows will become less and less common. Race conditions will be the next common vulnerability and those are harder to exploit which decreases the number of potential black hats. At least, that's what I've read and it makes sense to me.

Could you tell me what you mean by "command access"? I'm wondering if kernel-level access control mechanisms like systrace make it more difficult to exploit local vulnerabilities. The recent realpath() overflow seems to be a good example of potentially dangerous and common local vulnerabilities, but I still think that things are improving generally.

This might be a bit off-topic, but have you ever heard of a host-based IDS called Samhain? I've been playing around with it on some of my own computers here at home and it strikes me as being a pretty impressive and powerful piece of software. It might go a remarkably long way towards protecting hosts.

[ Parent ]
Bad advice (none / 0) (#99)
by greenrd on Sat Aug 09, 2003 at 05:50:49 PM EST

Unfortunately, bad advice may be in effect creating local root exploits which don't exist in distros. For example, on the Linux Annoyances list, two people just advised someone to use sudo to be able to rpm -i software without a root password.

Unfortunately this acts as a local root exploit, because rpm packages contain scripts which are run when you install (pre- and post-install scripts).


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

sudo can be a tricky tool (5.00 / 1) (#104)
by edward on Sat Aug 09, 2003 at 07:14:46 PM EST

because there is more than one way to configure it's behaviour. Yes, you can configure it such that you don't need to input a password to run scripts as root, but you shouldn't. If you're the only administrator on the machine, you should configure it such that only your user can use sudo, and configure it such that you still have to input your own password whenever you run it. But to suggest to someone that you should have it so that you don't have to input any password to use sudo is ridiculous and totally defeats the purpose.

[ Parent ]
One of the first ISPs I worked at (none / 0) (#144)
by xL on Mon Aug 11, 2003 at 03:32:07 AM EST

Had an owner who was still somewhat reluctant to give out root passwords. I spent the first few weeks working as a sysadmin there with only access to a sudo-script that allowed me to su to a customer account. The sudo-script was a wrapper to the /bin/su command that did some checking on the provided username. By passing the sudo-script a flag for su (something harmless like -f) instead of a username, it nicely gave me the root access I needed though. That was the point where the owner shrugged and gave me the password list. First I did was fix that script :).

[ Parent ]
Hrm... (3.75 / 4) (#51)
by edward on Sat Aug 09, 2003 at 01:08:21 AM EST

I've been trying to write a nice rebuttal to your claim that things are getting worse in computer security, and that if we're not careful we're all going to be hit with a huge "cyber-terror attack" (whatever the hell that is) but I'm tired and grumpy today. I'll just say that your conclusion is wrong-- things are not getting worse in IT security, they are getting better. The problem is more akin to what your intro seems to indicate. There lots of stupid users out there who don't really have any idea of what they are doing. While I certainly agree that there is a small subset of hackers out there with the skills to do some serious damage, even a non-elite-expert administrator can lock down her machine well enough to stop all but the most elite. And if you are targetting a system defended by an elite administrator, well, chances are she'll already know you're knocking on the door before you even walk up the steps. There are lots of things you can do to seriously ameliorate the dangers you've outlined here, and I just think that this article drums up a lot of worry over very little.

That's the whole point (4.66 / 3) (#57)
by xL on Sat Aug 09, 2003 at 03:04:54 AM EST

The closer we are to 'perfect security', the more people there will be who will not actually verify their security and the easier it will be to not do that. Ten years ago, incompetent wankers like the admin of that debian box would not be running internet hosting services. We have progressed enough now for that to be possible. How can it be that if technology matures even more this pattern suddenly no longer applies?

[ Parent ]
Hey, I partly agree.. (4.00 / 1) (#82)
by edward on Sat Aug 09, 2003 at 09:54:07 AM EST

Yeah, I partly agree with you. I also agree that black-box appliances can cause problems. But a 'cyber-terrorist' attack? On what infrastructure? Terrorists don't waste their time trying to bring down e-bay.com for a few hours as a way of spreading fear and uncertainty in the population. The people in danger of having their Linksys appliance owned really only have provided a Denial-of-Service attack clone. As the future progresses, these kinds of attacks will be nothing more than nuisances, if they're not just that already. Misison-critical machines performing even remotely important tasks are being taken off of the publc internet, if they were ever even there in the first place.

Over time, things will get better. And, hey, if you're right, that just means that the admins who know what they're doing will get and keep jobs while those that don't, won't. And that only seems to be a good thing to me.

[ Parent ]
Right now, it's useless (4.00 / 1) (#87)
by xL on Sat Aug 09, 2003 at 11:21:44 AM EST

I'm not too futuristic to think this IP gig is going to get into everything, though? The more it creeps into our lives, the more we will take it for granted, so the less we will actually know about it. IP, right now, looks like it's going to be the core of all communications. Telcos are migrating to it. Cable companies are using it for their digital subscriber TV. It may take another 2 or 3 decades, but at some point the distinction between 'ethernet patch' and 'phone jack' and 'wifi hotspot' will stop being there. If we're as dumb at that point as we seem looking from over here, we're fucked.

[ Parent ]
Well, you're typographical error? is interesting.. (none / 0) (#89)
by edward on Sat Aug 09, 2003 at 11:34:05 AM EST

Well, I still think I agree with you, though I'm not sure if I know what you're saying. First off, do you mean IT instead of IP? Because even if you don't assume that mistake, your comment still makes sense to me. Intellectual property stuff like TCPA and DRM could end up permeating digital devices, which might make every device a black box.

If you meant IT, and not IP, then I still sort of agree with you, but with some caveats. I mean, I'd like to think that the infrastructure market; i.e., carrier-grade equipment, kind of has to be robust and, by extension, secure. I think that in the course of the next two or three decades, at the same time that tight integration occurs, the technology becomes more robust and capable. I just can't envision a huge increase in ubiquity without a parallel increase in quality.

[ Parent ]
I meant the Internet Protocol (none / 0) (#102)
by xL on Sat Aug 09, 2003 at 06:38:53 PM EST

Sorry for being so ambiguous, must be something I ate.

[ Parent ]
"Carrier Grade" (none / 0) (#164)
by Metatone on Sat Aug 16, 2003 at 10:21:48 AM EST

In my experience, "Carrier Grade" equipment actually brings a whole new set of problems along with it. For the moment at least, performance of carrier equipment is often pushed to the limit. Understandably, this means specialist designs, home brewed work-arounds and hurried patching. There are vulnerabilities, especially if you can "social engineer" even one part of the chain you need to follow. From my experiences in the business, this isn't about to change any time soon. If you think back to the Kevin Mitnick story (sorry for the cliche) his exploits of "carrier systems" (Telephone company stuff mostly) often followed the MO:

- Learn about vulnerability in $big-routing-box
- Use social engineering to obtain the password to said box (which carrier employees treated as a black box and were quite used to giving out the passwords to contractors)
- Use password with said vulnerability into a means to "own" the box.

The social conditions for this remain in place with many Internet carriers. It's worth remembering that if the "cracker" is unobtrusive (rather than a cyberterrorist intent on spectacular effects) the "crack" of the box can remain undetected for a long time, especially on a specialised black box which may lack adequate auditing tools.

[ Parent ]

Yet another reason for TCPA (4.00 / 2) (#54)
by Dracolith on Sat Aug 09, 2003 at 02:27:21 AM EST

If the kernel images were digitally signed, then the s integrity could be verified repeatedly by various redundant routines both during and after the bootup process.

Of course a better security mechanism at the hardware level would be very useful.



If it's in the software firmware... (5.00 / 3) (#79)
by loucura on Sat Aug 09, 2003 at 08:50:14 AM EST

then TCPA won't be any help at all. TCPA won't touch the firmware of other hardware within the system.

[ Parent ]
Yup. (3.50 / 2) (#68)
by the77x42 on Sat Aug 09, 2003 at 04:16:36 AM EST

Set-it-and-forget-it systems are all over the place. My first employer had unpatched NW3, NW4, and NT4 servers all over the place. My last employer had an unpatched TS/WIN2K machine fully exposed to the internet (and was also running Kazaa) as their main server.

While I am tempted to immediately bash these companies for not maintaining a proper security program, it is costly and time-consuming. Has anyone actually worked for someone who got seriously hacked do to improper security? I've been to a lot of shitty setups, but never was has anyone been compromised, even when they were getting thousands of relay attempts per day.

Staying on top of security patches for dozens of servers (especially on Windows) can be a real pain. Something new needs to come along, if the threat is real. Somehow, however, I think security threats are slightly out of proportion.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

Oh hell yes (5.00 / 1) (#76)
by Bartab on Sat Aug 09, 2003 at 05:24:26 AM EST

Has anyone actually worked for someone who got seriously hacked do to improper security?

This year in fact. I replaced an admin because a months-old SSH exploit was used to enter a company, rootkit a good chunk of machines.

In the end, the admin in question never really got caught, rather somebody got cocky/flagrant/whatever and checked code into CVS.

End result: My employment, 30+ servers rebuilt, and CVS restored from months old backup and each logged checkin verified before being applied.

--
It is wrong to judge people on the basis of skin color or gender; therefore affirmative action shall be implemented: universities and employers should give preference to people based on skin color and gender.
[ Parent ]

Got r00ted (none / 0) (#77)
by AngelKnight on Sat Aug 09, 2003 at 05:49:11 AM EST

Yup.  Not for reasons of incompetence necessarily either.  But, I think my story drives the point home even though it didn't happen due to flagrant stupidity on anyone's part: "*know* your gear".

Once, I was managing a colo farm as a company's employee.  The company became unable to retain me, but they didn't take the servers down just because the last Linux guy was no longer on staff.  However, they didn't know to regularly update the boxes either.  Then, this year a rootkit appeared.

The remaining technical staff *knew* to patch up Windows servers regularly; the Windows boxes in the colo were patched up just fine.  The Slackware boxes were not.

(Okay, maybe I take it back: perhaps it was stupid for me to set up the production boxes with Slackware considering the relatively larger effort required to keep it up to date compared to, say, Gentoo or RedHat.)

[ Parent ]

Linux is not a free security pass (4.25 / 8) (#86)
by Lankiveil on Sat Aug 09, 2003 at 11:08:16 AM EST

From having worked at an ISP, I confirm that this attitude is prevalent at many a shop.  Linux boxes are invincible!  Linux boxes are not only invulnerable, they will actively respond and hack the script kiddie!  Linux boxes will solve world hunger and poverty!  

The people who have these attitudes are almost always the ones who are the "open source advocates".  I'm sure you know the ones I'm talking about.  The ones who spell "Microsoft" with a dollar sign.  The ones who call in sick the same day as the Dr Who marathon.  The ones who wear tshirts with Star Trek characters on them (not saying those two shows are bad, but please, there are limits).  Those of us who were weaned on Windows-based systems, who are a lot more pessimistic on security, are usually pretty on the ball when it comes to Linux security, installing patches as they come out and whatever.  But the other crowd, they just seem to have this arrogant "It's open source, it'll never be hacked!" attitude.

Of course, there are Windows experts who are completely incompetent with security, and Linux guys who take security seriously.  Just saying that these two personality types seem to be dominant from what I've observed.

so what? (3.00 / 1) (#92)
by cronian on Sat Aug 09, 2003 at 03:50:13 PM EST

If computers are used to host sensitive information, then they should be secure. However, why should bussinesses worry about some kid installing a rootkit on some webserver, so long as it keeps serving whatever web pages it is supposed to serve? Most of the computers that are hacked contain no sensitive information. DDOS attacks are possible, but why should Joe Inc. care unless it affects them?

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
sniffing. duh. (none / 0) (#111)
by turmeric on Sat Aug 09, 2003 at 08:12:04 PM EST

alot of sites (ebay) still dont encrypt passwords. you could seriously screw people up by sniffing their data. identity theft.

[ Parent ]
depends (none / 0) (#161)
by cronian on Tue Aug 12, 2003 at 11:48:00 PM EST

eBay should have strong security on their webserver, but is less important for the home user, who really shouldnt't have any open ports. Sniffing can be a problem, but so long as the company handling sensitive information deals with the porblem the user doesn't really have to do much. However, most companies shouldn't have much sensitive information outside their firewall, or outside of individual's computers.

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
[ Parent ]
All I can say is... (3.66 / 3) (#95)
by jd on Sat Aug 09, 2003 at 04:43:09 PM EST

...Idiots.

Front-line machines should never store valuable data, for a start. They should be firewalls, maybe proxy servers or NAT devices, but never more than that.

In an ideal world, you should then have a second layer. This would consist of caches, Intrusion Detection systems and emergency shutdown code, to disable access to a server if a serious threat arises.

Finally, your server(s) should have strict controls over root access. Remote root logins should not be permitted, for example. In fact, any root login, other than by a logged-in user, should really never be permitted.

Once you've established your lines of defence, and your servers, routinely check them with Nessus or some other security scanner. Use tcpdump to log any network traffic that isn't specifically authorized. Use tripwire to verify no unauthorized installs/modifications have been made.

None of this is complicated. None of this is beyond a 12-year-old's comprehension. You can build a dedicated firewall box for a couple of hundred dollars, max, and can probably buy them for less, if you know where to go.

No. Security flaws are the consequence of going on the cheap, going for a quick solution, and (above all) going for something that requires the least thought and preperation. It's hard to have sympathy for deliberate ineptitude.

Sure, even if you do all of the above, some machines will still be broken into. It happens. Get over it. The fact of the break-ins is not the issue, though. It's the number. If you can reduce the successful cracks by an order of magnitude or two, then sure there are still cracks. But it won't have nearly the same potential for catastrophe.

From a n00b (none / 0) (#100)
by greenrd on Sat Aug 09, 2003 at 05:59:41 PM EST

Front-line machines should never store valuable data, for a start. They should be firewalls, maybe proxy servers or NAT devices, but never more than that.

Unless you've got really heavy traffic, what's the point of a dedicated firewall? Why not just set up a firewall on one of the hosts? What extra security does an extra machine buy you?

Remote root logins should not be permitted, for example.

Why not?

Prohibiting password-less remote root logins, I can see that. But what's wrong with a standard ssh root@host?


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

no remote login as root. (5.00 / 2) (#112)
by porkchop_d_clown on Sat Aug 09, 2003 at 08:44:02 PM EST

there's an obvious reason for this: it forces an attacker to move from a straight password attack to a 4-phase attack. Now, instead of simply guessing the root password he has to (1) determine a valid user id for the target machine. (2) crack that account. (3) Discover if the account has su or sudo privleges (if not, back to (1)). (4) NOW he can attempt to crack the root password.

Makes it a bit harder, no?


--
His men will follow him anywhere, but only out of morbid curiousity.


[ Parent ]
It's really two steps though (none / 0) (#143)
by xL on Mon Aug 11, 2003 at 03:26:08 AM EST

1 - Log in to existing user account using password found on an employee's Windows machine.
2 - Run a local exploit to gain root.

The number of machines I've seen or heard of getting rooted because someone guessed the root password can becounted on one finger and it isn't raised.

[ Parent ]

idiot (5.00 / 3) (#110)
by turmeric on Sat Aug 09, 2003 at 08:11:04 PM EST

a firewall doesnt have to contain senstiive information, it has it passing through it all day long.

[ Parent ]
Usually... (none / 0) (#130)
by jd on Sun Aug 10, 2003 at 02:25:02 PM EST

...people encrypt the sensitive data, prior to transmission from the secure server. IPSec is slowly becoming more prevelant. SSL, TLS and SSH are all widely used.

I assume people are familiar with the FIPS standards, and the practices required by, say, the US Government - sensitive information MUST be encrypted, using a known trusted implementation of a known trusted algorithm. These days, that means the AES - Rijndael - which is a very nice, fast, secret-key encryption algorithm.

Trust me on this. Have everything packaged up using AES, and Joe/Jane Hacker can do what they like on the firewall. They won't see a damn thing that's useful.

[ Parent ]

We have met the enemy... (none / 0) (#127)
by Bad Harmony on Sun Aug 10, 2003 at 08:16:59 AM EST

Why not replace the employee parking lot with a mine field and put machine gun emplacements on the roof. Anyone who comes within 300 meters of the company's computers will be fired on without warning.

5440' or Fight!
[ Parent ]

Because... (5.00 / 2) (#131)
by jd on Sun Aug 10, 2003 at 02:33:18 PM EST

...active defences are often a cinch to bypass. Passive defences are vastly superior, and much more cost-effective.

In this case, passive defences involve locking down the data in a way that makes unauthorized access very very difficult.

The first rule of security is that it's going to be broken. That's a given. True security is achieved not by buying more expensive, flashier, noisier, deadlier defences, but by making the potential damage less than the effort of causing the damage in the first place.

That's why the old Orange Book B[1-3] standards involved "mandatory access controls", rather than hot-wiring terminals to the live power line.

That's why FIPS deals with encrypting sensitive data, rather than implementing the "Black Ice" described in Neuromancer and the Shadowrunner series.

That's why IPSec is a lot more popular than hiring a hitman to take out the attacker.

These things are not more popular by chance, or because they're "legal". It's because they work, and the alternatives don't.

(It's also why the US has lost nearly three times as many people -after- combat operations in Iraq. Greater firepower doesn't give you greater security. Only greater bullet holes.)

[ Parent ]

while you (none / 0) (#146)
by wh4tn0w on Mon Aug 11, 2003 at 03:41:22 AM EST

sit up in your office with a .50 cal and a bourbon and rainwater reflecting on the poisoning of your natural essence ?

[ Parent ]
this sounds like (none / 0) (#145)
by wh4tn0w on Mon Aug 11, 2003 at 03:37:37 AM EST

the Swiss bank I work in.

[ Parent ]
tell us more (5.00 / 1) (#98)
by MannyDixn on Sat Aug 09, 2003 at 05:20:45 PM EST

I'd be curious to know as to what exaclty happened on your machine, how the intruder got in, what the rootkit did, what can be done to prevent this in the future.

Aside from satisfying my idle curiosity, it may be a wake-up call to some of these lax sysadmins you speak of, who may recognize elements of your compromized setup in their own machines. So do tell.
-- Nothing is real and everything is permitted.

Holes in the details (4.66 / 3) (#141)
by xL on Mon Aug 11, 2003 at 03:13:10 AM EST

You have to remember my primary focus was getting that machine in some working order so that data could be moved off elsewhere. The rootkit installed consisted of a kernel part and userland replacements for commands that would make it easy to find out what was going on, including ps, ls, md5sum, strings and grep. The kernel module hid directory entries with a configured suffix, protected a number of configured binaries from being replaced, logged network traffic containing probable passwords to a hidden directory, hid certain processes and had provisions for stealth remote access.

The process hiding didn't work out. The replaced binary for ps just generated an error and I could figure out what was going on by looking at /proc/*/cmdine and fishing out suspicious entries. The stealth access looked potentially interesting, although I think it didn't work out. On a system where it's designed for, it uses disguised packets aimed at regular ports (like http) to communicate with the client. The cracker wasn't so sure this module was going to help either, so just to be sure he stuck a rootshell on port 666 in inetd.conf and an ssh daemon configured to allow root login was started up on yet another port from a hidden directory, started from /etc/rc.sysinit.

Trying to replace a hacked binary with a known good version with the patched kernel running was futile. The kernel would report success on the cp/mv, butonce you took a proper look the old, hacked, binary was moved back in place.

The workings of these rootkits give a funny ring to people I see claiming on this forum that on a Linux system you always know what is going on, so it must be more secure than windows. This may be true, but a well-installed rootkit is designed to counter this and I estimate it does this well. The fact that Linux is stable and needs little maintenance for its primary tasks does make it easier for these rootkits to remain undetected for quite long. One slip in security is all it takes.

[ Parent ]

Cyber Terrorism (4.75 / 4) (#101)
by seraph93 on Sat Aug 09, 2003 at 06:07:02 PM EST

Cyber-terrorism may have a silly ring to it now, but we'd better start worrying about it before the problem is real.

I don't know about this term, and it goes farther than just having a "silly ring to it". I thought terrorism was supposed to inspire...well, terror. What's more terrifying, suicide bombers or script kiddies? What inspires more fear: the server going down, or a building or two?

"But OMG, Seraph, *these* script kiddies speak Arabic!"

Feh. I think it's just another catchphrase coined by the good old government so they can get more draconian laws passed. Stupid kids with rootkits are a pain in the ass, but I wouldn't go so far as to call them terrorists. There's a huge difference between replacing someone's webpage with "0wnZ0Rd j00, j00 f4G0rTz" and flooding a train station with Sarin, y'know?

In the dot-com bubble world, it was e-everything. eBanking, eCommerce, eToeCheese, whatever. Here in post-9/11 land, everything is terrorism. Somebody embezzles millions from their company, they're not an embezzler, they're a Financial Terrorist! Someone cuts you off on the highway? That's Automotive Terrorism! Someone rooted your box and erased all your porn? It was a Cyber Terrorist!

Actually, that last one's pretty damn scary. What would I do without my porn? Maybe we *should* call them Cyber Terrorists after all.
--
Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
one server, 500,000 people's life savings (3.00 / 1) (#109)
by turmeric on Sat Aug 09, 2003 at 08:10:22 PM EST

the WTC went down but very few of those people starved to death. most of them were rich and/or had insurance policies and/or rich friends/family.

i think you will find that when 50,000 minimum wage fry cooks have their life savings stolen, they are summarily evicted, fired from their job for not being able to take a shower or have clean clothes, and go roaming thru the streets unable to buy food, then you might see some 'terror'.

[ Parent ]

Life savings @ minimum wage ~= $200 (4.00 / 1) (#120)
by seraph93 on Sun Aug 10, 2003 at 01:40:29 AM EST

...when 50,000 minimum wage fry cooks have their life savings stolen...

Exactly how does this happen? I don't know where these fry cooks are doing their banking, but my bank has backup copies of its data made every day and stored off-site, completely inaccessable to the Internet. Should the worst happen, there are multiple redundant copies of said information kept on *paper*. Amazing how something so apallingly low-tech can foil these devious, new-fangled eSchemes.

I suppose that identity theft is a possibility, and one that is facilitated by so much business being done online, but please. Imagine that you are one of the fry cooks in question. If you and 49,999 other fry cooks call up your bank and insist that no, you did not authorize the transfer of your entire savings to the account of one Mr. Moustafa Al-Tayyib, I think you'd probably get a refund. The FBI would probably get a call or two as well. If it was as easy as you suggest, it would have been done already. Hell, I'd have done it already, and I'd be sittin' on a fjord somewhere sippin' at some single malt right now, instead of feeding trolls on K5.
--
Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
[ Parent ]
Current discussion of "cyber-terrorism" (4.50 / 2) (#142)
by xL on Mon Aug 11, 2003 at 03:23:02 AM EST

Is a futile attempt of government think thanks to sound hip to their money sources. In the foreseeable future, the risk is one of annoyance, not necessarily life threatening. We are moving towards internet technology in every day devices at rapid pace, though. Right now, attacks on internet infrastructure only disable people's ability to look at some of the porn. Admittedly that's not really something to raise the Homeland Defense-o-Meter from puce to indigo for.

Now imagine that telephony and entertainment (TV) will migrate to tcp/ip. A telephony outage can be serious enough. There may be other unique items in our personal lives that, in the future, will rely on internet technology. I cannot conclude otherwise than that attacks on internet infrastructure will grow over time in their ability to inflict monetary and selected physical damages.

[ Parent ]

Excellent points (nt) (none / 0) (#158)
by seraph93 on Mon Aug 11, 2003 at 07:01:07 PM EST


--
Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
[ Parent ]
Troll (1.33 / 6) (#103)
by Tezcatlipoca on Sat Aug 09, 2003 at 06:58:49 PM EST

And nobody noticed.

Most security experts agree that Linux machines are safer, more easily patched and fixes to vulnerabilities are faster.

Continuing with your healthy feeding Trolly, I would like to add that all what you spewed applies exactly the same to any platform.

In Linux and UNIX at least you have got a chance to find out what is going on. In Windows you have the registry and MS discontinuing support (and thus security fixes) of perfectly working (for MS standards) machines. At least Apple saw the light and moved to something more UNIXish.

Might is right
Freedom? Which freedom?

That's more of a troll (5.00 / 2) (#105)
by CaptainSuperBoy on Sat Aug 09, 2003 at 07:41:28 PM EST

Your comment is more of a troll than this article. MS continues to provide security fixes as far back as Windows 98 - does Red Hat continue to write fixes for versions 4, 5, etc?

The registry? How does that keep you from knowing what's going on? This kind of comment would only come from a Linux zealot who knew little about the platform or company he was accusing.

--
jimmysquid.com - I take pictures.
[ Parent ]

Not a problem! (none / 1) (#153)
by vetgirig on Mon Aug 11, 2003 at 04:53:50 PM EST

With Red Hat you have the source. You can always fix the problem yourself(*) if you really need too.

With Windows 95 you have no such option!

PS Or hire someone to do it for you.

[ Parent ]

You could do that (none / 0) (#156)
by Cloaked User on Mon Aug 11, 2003 at 05:37:32 PM EST

Of course, unless it's a very simple, one-off fix, it'll almost certainly be cheaper to just upgrade your OS, depending on how many machines we're talking about here.

--
"What the fuck do you mean 'Are you inspired to come to work'? Of course I'm not 'inspired'. It's a job for God's sake! The money's enough and the work's not so crap that I leave."
[ Parent ]
10000+ (none / 1) (#166)
by vetgirig on Mon Jun 07, 2004 at 06:34:20 AM EST

With 10000+ machiens that has software that requires a specific version of software not available elsewhere - its much cheaper to make the fix.

[ Parent ]
your problem (2.70 / 10) (#106)
by turmeric on Sat Aug 09, 2003 at 07:46:32 PM EST

is that you are a lazy whiner.

linux is perfect. ESR said so. all bugs are shallow.

who are you, pig, to speak against this?

you need to admit your wrong thinking to the group
you need to struggle with your anti linux feelings

we will help you see the light of the great ESR

open source software has good security

perhaps if you would repeat that deaily before
breakfast you would not have so many difficulties

look how many others have successfully kept out hackers with linux? could it be that it is not something wrong with the system, but rather, something wrong with you, comrade?

why is it that you would blame first the benevolence of the open source? rather than your own failings?

this is the pattern we see that must be stamped out for a greater open source future. the great open source ESR would say that our doubts come from fear and ignorance. you only need reeducation to accept the truth of the way of the open source and ESR is the right way.

dont you see what you are doing by resisting?

scoop is perfect. it represents the interest of the people because it was written by an open source enthusiast. and to be an open source enthusiast means to care about the people. the users. to think otherwise is to be against everything open source belives in... to be against the people.

are you against the people?

no comrade, of course you arent. repent while it is not too late. please apologize for thinking this way and think rightly instead of wrongly.

oops (5.00 / 1) (#107)
by turmeric on Sat Aug 09, 2003 at 07:47:32 PM EST

'scoop' / 'security in linux'

[ Parent ]
You're so obvious it's not even remotely funny /nt (3.50 / 2) (#114)
by JetJaguar on Sat Aug 09, 2003 at 09:08:50 PM EST



[ Parent ]
(lol) (none / 0) (#121)
by seraph93 on Sun Aug 10, 2003 at 01:56:41 AM EST

linux is perfect. ESR said so. all bugs are shallow.

That's just too funny. You get a 5 just for that.
--
Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
[ Parent ]
have you been living under a rock? (none / 0) (#123)
by JetJaguar on Sun Aug 10, 2003 at 02:47:35 AM EST

Every parody of ESR has been saying this exact thing for the last 5 years, at least.

It's not even funny anymore, it's just boring.

[ Parent ]

I dunno (4.00 / 2) (#137)
by seraph93 on Sun Aug 10, 2003 at 10:54:32 PM EST

It just struck me as being quite funny for some reason. Sorry. As long as we're on the subject, is there anything else I'm not allowed to laugh at?
--
Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
[ Parent ]
fix for the flash update problem (4.50 / 2) (#108)
by Smaug the Golden on Sat Aug 09, 2003 at 08:04:19 PM EST

Any hardware that can be flash updated should require a jumper to be set before the hardware will allow it. It can be shipped with the write jumper set, and security concious people can just remove it before they put it in the computer for the first time. As long as you boot from a trusted floppy/cdrom to do the update and remove the jumper right after the update, the problem is pretty much gone. Not a new idea, but I don't think it has been done yet.

alot of places do that (none / 0) (#116)
by omegadan on Sat Aug 09, 2003 at 09:43:33 PM EST

Sun hardware for instance for the exact reason mentioned ... although I used to scream bloody murder when I had to upgrade a slew of machines (new solaris OS's frequently required a new BIOS).

Religion is a gateway psychosis. - Dave Foley
[ Parent ]

Hardware Jumpers (5.00 / 1) (#157)
by Bad Harmony on Mon Aug 11, 2003 at 05:38:48 PM EST

The jumper may not protect you in every case. I ran across a motherboard, think it was ASUS, where the jumper only worked if brand A flash was installed on the board. If brand B flash was installed, the jumper was ignored. What brand of flash was installed on your board was dependent on the production run.

5440' or Fight!
[ Parent ]

Linux is teh cool! (none / 0) (#126)
by Cameleon on Sun Aug 10, 2003 at 08:02:00 AM EST

Jeff K. knows.

I wish Mark Twain had been alive (3.00 / 2) (#133)
by Kasreyn on Sun Aug 10, 2003 at 07:20:48 PM EST

to read this paragraph:

There is a clone army of never updated Red Hat 5.2 machines out there in the big world, and you can trust the fact that 98% of them have since been cracked into by one or several script kiddies merrily using them for their IRC bots or DDoS drones. You can also be assured that these machines will remain to be 'owned' like that for averagely one year. These parasites are a problem that is currently hardly accounted for. Only on the shady world of IRC people get a glance of this emerging problem, where 15 year old pimplefaces with a collection of tarballs and perl scripts are able to warlord thousands of dollars of infrastructure damage at a whim.

I'm not exactly certain what language this is written in, but it DEFINITELY is not English. This article was not in edit long enough; either that or jjayson was asleep.

As to the subject matter (when it wasn't incomprehensible due to poor English skills): a very interesting and timely read.


-Kasreyn


"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
Eh? (none / 0) (#140)
by xL on Mon Aug 11, 2003 at 02:54:42 AM EST

Admittedly I can be longwinded, but is there anything actually wrong in the part you quoted? If I'm that terrible an English writer, it would be helpful if you pointed out the mistakes.

[ Parent ]
As a random example (none / 0) (#150)
by greyrat on Mon Aug 11, 2003 at 11:10:30 AM EST

You can also be assured that these machines will remain to be 'owned' like that for averagely one year.

Might be better written as:

It is highly likely that machines compromised in this way would remain 'owned' for a year on average.
~ ~ ~
Did I actually read the article? No. No I didn't.
"Watch out for me nobbystyles, Gromit!"

[ Parent ]

I'm seeking professional help (none / 0) (#152)
by xL on Mon Aug 11, 2003 at 04:11:41 PM EST

It's either that or beat myself with a mallet every time I forget to keep my language simple and clear. Thanks for pointing it out.

[ Parent ]
some pointers (5.00 / 1) (#159)
by Kasreyn on Mon Aug 11, 2003 at 11:42:29 PM EST

You can also be assured that these machines will remain to be 'owned' like that for averagely one year.

Averagely is not even remotely a word. Rephrase to:

"You can also be assured that these machines will, on average, continue to be 'owned' like this for one year each."

These parasites are a problem that is currently hardly accounted for.

VERY clumsy; not actually bad grammar per se. Also impossible to figure out what you mean.

"These parasites are a problem that currently is hardly accounted for."

Only on the shady world of IRC people get a glance of this emerging problem, where 15 year old pimplefaces with a collection of tarballs and perl scripts are able to warlord thousands of dollars of infrastructure damage at a whim.

That sentence is a nightmarish monstrosity. Its errors:

Only in the shady...

...of IRC do people get...

...a glance at this... You may be thinking of glimpse. You get a glimpse OF; you glance AT. Easy to remember, since glance has an "A" in it.

By the way, at "where" you begin a subclause that would belong much more properly behind "IRC". This would make the entire thing much more clear.

15 year old, should be 15-year-old.

...with collectionS of... (note lack of "a"; plural kiddies requires plural collections)

Warlord is not a verb. Hoard might work better. Even though a warlord leades a horde, warlord does not work.

"dollars of infrastructure damage" is grammatically meaningless.

Suggest complete rewrite of the last sentence to:

"Only in the shady world of IRC, where 15 year old pimplefaces with collections of tarballs and perl scripts are able to commit thousands of dollars worth of damage to the network infrastructure at any moment, do people ever get a glimpse of this emerging problem."

Hope this helped. Cheers,


-Kasreyn


"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
[ Parent ]
Have you ever done "auto-correction"? (none / 0) (#163)
by ultimai on Thu Aug 14, 2003 at 11:38:14 AM EST

I thought the piece was written well enough. But now you point out those those errors, I realize that I automatitically corrected the grammer while reading it.  My father does so when reading out loud first draft essays and such, and many other people probably do.

Ex:
The hare
loved the
the world,
as lovely
as it was.

[ Parent ]

Threat model (3.50 / 2) (#149)
by Paul Johnson on Mon Aug 11, 2003 at 10:31:00 AM EST

The author seems a bit confused about what he is trying to say. First he talks about unpatched RH5 servers that can be rooted by script kiddies. Then suddenly he talks about theoretical (though probably feasible) attacks on Flash BIOS code. Ken Thompson's article Reflections on Trusting Trust looks at similar modes of attack at the compiler level. Since this article is supposed to be about the future, how would MS's proposed Palladium chip affect such an attack? Then the article goes off on another tangent about colocation security, and ends with a vague reference to cyber-terrorism.

What is missing from this is a threat model, something that should be the starting point for any discussion of security. The threat model looks at questions of who, what, where, how, and how much:

  • Who: who are we trying to keep out? Script kiddies, Leet hackers, techno-spies, terrorists or what?
  • What: what are they trying to achieve. A script kiddie may feel that one day of DDOS constitutes success. A spy or terrorist is unlikely to agree.
  • Where: where are they? Inside the company, or outside? Most serious security breaches are committed by insiders, and security is a very thorny issue to do with how much the company security people are entitled to know about employees.
  • How: how are they able to attack us? Physical attacks require one form of security, network attacks something else. Even Leet hackers are likely to restrict themselves to dumpster diving. Physical penetration of an even moderately secure site runs too many risks. Terrorists and spies have the resources to either get a job with you or suborn an existing employee, which takes you back to the insider attacks mentioned under "Who".
  • How much: what resources do they have, and how much an they spare for an attack on you? Limited resources mean limited options for attack, which in turn limits the response you need to make.

Once you have a threat model you can then look at your asset inventory and work out what it needs to secure it against the threats identified in the model. This brings a whole bunch of problems in itself. Lots of small organisations (and some big ones) can't or won't spend the time and money required to do all this. Never mind all the individuals with broadband Internet. And even large organisations with effective IT departments have a problem with people keeping assets off-register, often because they want to avoid all the hassle the IT department will give them for it.


You are lost in a twisty maze of little standards, all different.

A large part of the solution... (none / 0) (#165)
by GhostfacedFiddlah on Sat Aug 16, 2003 at 01:37:40 PM EST

...is enforcement.  Even if you go through all the trouble to hunt down the name, address, and favourite ice cream of the kiddie who r00ted your box, you're not likely to see anything come of it.  The FBI has bigger problems on their hands, and the police often have no clue.

And so the kiddies continue unabated.

I humbly suggest that if an IP, a time, and clear evidence of an attack were all that was needed for action to be taken, hack attempts would be cut 90% - if not more.  Right now, there's no incentive for someone who's noticed the problem to follow up - nothing will come of it.  There is absolutely *zero* deterrant for most hackers who just want to stir up some trouble, or prove that they're 1337.  If you're not stealing tens of thousands in *material* wealth, then you are simply not worth the effort.

Start enforcing the law, and you'll see more effort put into finding the perpetrators, and you'll see less people interested in perpetrating in the first place.

It's like locks on a house - the are in  no way "secure" as we expect our OSs to be, but the law provides the rest of the deterrant.

Security Risks: A Look into the Future | 166 comments (145 topical, 21 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!