Post a Comment
From www.openbsd.org:
"Some other open source operating systems are commonly distributed as CD-ROM ISO images. This is not how OpenBSD is distributed."
Some unofficial (and of course unsupported by OpenBSD team) install ISOs here:
http://www.hup.hu/modules.php?name=News&file=article&sid=9953
You can easily make your own isos:
http://www.pantz.org/os/openbsd/makingaopenbsdcd.shtml
This is discussed many times, the OpenBSD peeps mean by "remote hole" a method to really access the system. Thus remote vulnerabilities do not count unless there is a method to gain some rights on the system.
I'm very pleased to see a new release with again some amazing features and can't wait to try out to play with the new RAID tools. But first I need to buy myself a LSI/AMI card 
And that's what the talkd vulnerability is, a daemon that is enabled by default. I remember reading different description on their webpage years ago (or it may just be a different part of it) which said whether or not it was exploitable was 'inconclusive' since no one bothered to develop an exploit. In other words, they didn't count it because no one had proven it to be exploitable, not because it was proven otherwise. It sounds like a whitewash to me.
RE[3]: ONE remote hole?
RE[5]: ONE remote hole?
"talkd is not enabled by default."
That's where you would be wrong. In version 2.8 and earlier, it was enabled by default. It was only AFTER the vulnerability occured that they disabled it by default, in the 2.8 install: http://www.openbsd.org/plus28.html
They even disabled fingerd by default in 2.8 as well. They were trying to cover their asses so they could keep making that bogus claim.
http://www.killsometime.com/video/video.asp?ID=327
http://video.google.com/videoplay?docid=-7153152098207965240
"Having a hole that could, some time in the past, have been exploited doesn't count as a remote hole."
Of course it does, otherwise you can discount ever remote hole that has ever been fixed.
"You have to have a workable exploit on the current version (at the time)."
Why must the exploit have to be created at the time the vulnerability was first discovered? That makes no sense. A remote hole is a remote hole regardless of whether or not it's been exploited.
I'm sure that there still are lots of potential holes in the current distribution but the point is, they're so hard to find that nobody knows where they are or how to exploit them.
"if you find a hole in a daemon that has been disabled in the current version it doesn't count (or did they find that hole before 2.8 came out?)."
You don't understand, when the vulnerability was discovered in 2000, talkd was enabled by default. The OpenBSD team disabled talkd by default BECAUSE OF the discovery of the vulnerability.
"is != was. "
At the time when the vulnerability was discovered, talkd was enabled by default, so you can't discount it.
"And unless you can provide a proof of concept talkd exploit or prove that it's actually remotely exploitable the claim, for what it's worth, isnt invalid."
That makes no sense, why should the burden of proof be on me? No one has proven that it's NOT exploitable, so following your logic, I could conclude that it MUST be exploitable.
"malloc(3) has been rewritten to use the mmap(2) system call, introducing unpredictable allocation addresses and guard pages, which helps in detecting heap based buffer overflows and prevents various types of attacks."
This is such a modest way to introduce a radical change in memory management. OpenBSD is the first OS to really use the MMU to protect from buffer overflows in the Heap.
A presentation by Theo de Raadt on some of the security improvements implemented by OpenBSD
http://www.openbsd.org/papers/auug04/index.html
The OpenBSD 3.8 song - actually this is just a narrated story, but the other songs on the page are pretty good.
http://www.openbsd.org/lyrics.html#38
http://mirror.phy.olemiss.edu/mirror/openbsd/songs/
Edited 2005-11-01 14:53
Great work. Especially the sasyncd. Keep on OpenBSDing.
polarizers 2cent
http://www.codixx.de/polarizer.html
http://php.khk.tartu.ee/~alari/?p=2
It's not in english, but the commands are pretty much explaining, what to do.
Yes: X, KDE and Gnome are all supported. Hardware support is not as good as Linux and Windows (due to its minority status) and possibly worse than other BSDs due to the organisation's refusal to accept closed-source drivers.
That said, I'm not sure if KDE and Gnome are part of the core distribution. OpenBSD is really aimed more at secure servers and workstations rather than "normal" servers and workstations. For example, they still use Apache 1.3, even though it's slower than 2.x, because they know their heavily modified Apache 1.3 is secure, but can't say with any certainty what Apache 2.x is like.
OpenBSDs aim is not geared towards anything in particular. It's developed with the developers in mind. Nothing else. It's developers want a stable, secure and totally free OS. That comes at a price. X w/patches is included and I think the window manager is TWM by default. KDE/GNOME/others are available as part of ports.
Can be made to do just about anything. Defaults to FVWM, but any WM will work. Thousands of "ports" like FreeBSD. Multi-arc OS. I run it on PPC, SPARC, and x86, in fact, OpenBSD has worked quite will on every system I've tried.
It can take only minutes to install. Easy network configuration. The list goes on. For those wondering what you can do with OpenBSD, in my case I have a PPC (G3) server, and several (P200, P150, SS20) clients (X-Terminals), even my laptop (Compaq 1210) runs OpenBSD. So for me, OpenBSD does everything I need.
I have excellent uptimes, some reaching close to one year, this OS has been *very* stable for me.
The other thing I like about it is, it doesn't have 8 DVDs worth of stuff to install, only a couple hundred megs, add more/less as you want.
OpenBSD Rocks! Thanks Theo and Gang!
Having a hole that could, some time in the past, have been exploited doesn't count as a remote hole. You have to have a workable exploit on the current version (at the time). I'm sure that there still are lots of potential holes in the current distribution but the point is, they're so hard to find that nobody knows where they are or how to exploit them.
I'm not knowledgeable on the history, but it seems to me that if you find a hole that you can't actually exploit then it doesn't count and if you find a hole in a daemon that has been disabled in the current version it doesn't count (or did they find that hole before 2.8 came out?).


