Slashdot Mirror

I ran into the same disk issue mentioned on the Calyptix blog when trying to run OpenBSD. The last comment on the blog says if you select a Win98 disk it will resolve the issues. I havent tried it yet.

Knowing the username and password is a separate way of using this attack, in which they trick you into (first) logging in and (then) doing the bad stuff.

This is one of the reasons that home routers, which often use HTTP Basic Authentication, are ironically more secure: HTTP Authentication pops up that annoying box we all hate. It's a pretty big signal that Something Weird Is Going On.

See Drive-By Pharming at http://www.securityfocus.com/archive/1/460251 or the article linked from TFA, http://labs.calyptix.com/csrf-tracking.php

Good question. I haven't spent much time with any BSD system, but I've spent enough with SELinux (personal pet peeve: it's not `SE Linux', though `SElinux' or 'selinux' are acceptable) to know a bit about the difference. Pardon me if I wax loquacious...

In the computing world, the vast majority of security flaws come from bugs: improper handling of untrusted data leads to buffer overflows time and time again. Fix the bugs, and those security flaws go away. However, what about the ones you didn't catch? Someone is perfectly capable of discovering them, and exploiting them, until you discover the same problem and fix it. It's a vicious cycle, and you can never win: there's always another security hole, because there's always another bug. The security holes from bugs you haven't found yet are known as zero-day attacks, since any patches to the bugs have existed for zero days (or something like that).

The OpenBSD solution to the threat of zero-day attacks is to spend lots of time looking at its code, and reviewing its code, and testing its code, before vetting it to be `secure' enough to use. They do an excellent job: I don't know particulars, but I'd guess that an OpenBSD system out of the box is more secure than even a no-frills Linux distribution. They lock everything down, and generally don't run software that hasn't been tested thoroughly. Note, however, that you can poke holes in your shiny OpenBSD system by downloading and installing buggy code: Try any poorly-written FTP server, for instance, and watch your box get 0wnd.

The OpenBSD approach shouldn't really be seen as a choice, because every operating system that wants any hope at security needs to go through this process, of reviewing code time and again, and squashing those bugs dead. The deviation from other operating systems is the point where the code is declared to be `good enough', and put into production. OpenBSD developers are just really careful about declaring software to have reached that point. But they aren't perfect. Go to OpenBSD's website, and notice the text that says "Only two remote holes in the default install, in more than ten years!" Pretty good, right? Yup. However, as recently as three months ago, that read "Only one remote hole [...]". What gives? OpenBSD didn't handle some obscure IPv6 stuff right, and it was found that someone could run arbitrary code through this bug.

Does this mean that OpenBSD is a failure? No, though it does mean that they failed in their (rather lofty) goals at least twice (that we know about; I maintain they should change the banner to read 'Only X remote holes in the default install, in the last Y years, that we've discovered so far!'; but, that's just me). This doesn't (shouldn't) besmirch their reputation, and the OS is still one of the best, I'm sure. But ultimately, things like this will happen again; and inevitably, some cracker one day will write an OpenBSD exploit, and steal millions of credit card records because of an OpenBSD system which had a security hole, while the owner of the system believed it to be secure. In short, it's like most any other publicly available operating system: it tries really hard to be secure; and it is probably more secure than any of them, according to their accepted definition of having no security holes. It is an excellent goal, but it's ultimately impossible.

SELinux, which is the core of what was required of Red Hat Enterprise Linux 5 to pass this certification, is a very different approach to security. There're tons of things that go in to making SELinux, but I'll try to keep things as succinct as possible, at the risk of leaving (hopefully unimportant) things out. SELinux operates on the principle of `domains', which are made far more abstruse than they need to be. A domain is a

At http://www.calyptix.com/ we have a lot of success with our signature less inspection engine, DyVax. This includes stopping the Storm Trojan and Nuwar malware hours before the big vendors saw samples on their honeypots. Reliance on signatures creates costly downtime, we are trying to eliminate that.