Slashdot Mirror
OpenBSD Gets Even More Secure
Telent writes "As seen in this post by Theo de Raadt, OpenBSD is getting even more secure, working on smashing script kiddies running buffer overflow exploits dead. Tightening PROT_* according to the POSIX standards and creating a non-executable stack on most architectures are just two of the recent enhancements, most of which are in -current now."
If volunteers in an open source project can make an operating so secure, why can't a company with a lot more money and programmers not secure their operating system as good?
I like the way, BSD makes non-exec stack default. I think in the latest linux kernel, you can make it non-exec at compile but it is not default.
Consensus is good, but informed dictatorship is better
One day, Theo is going to decide that allowing people access to the HTTP port of the dist machine is just too big a risk, and OpenBSD really will be the most secure OS there is.
I think BSD will always have its place. It is secure for one thing. And nobody wants a GUI on their servers. Running XWindows can create security holes as well.
Consensus is good, but informed dictatorship is better
Yah, now If only I could run Open BSD on a system with more than _one_ processor. =/
-sithEnder
google cache, in case of server is slashdotted
A few other people would agree that OpenBSD is the most secure OS. Although I'm a Debian user, kudos to the OpenBSD team on their work.
Your hair look like poop, Bob! - Wanker.
X isn't insecure, really... oh wait, is that a window I hear breaking in the background... gotta go...
I think its good that organizations such as OpenBSD are taking the initiative to combat DoS/DDoS attacks. I see a lot of companies such as ISS and SecureWorks blowing smoke about "preventing hacker intrusion" when the real threat these days is worms such as Slammer. I really don't know a whole heck of a lot about DDoS attacks, but I've seen a lot of systems crumble under them, even if the os installed on the systems is unaffected. Wonder when Cisco will start doing things like this with IOS? (Unless they already are?) Discussion encouraged.
-===- "Those who would sacrifice freedom for security deserver neither" -===-
This, and other recent, articles about BSD have made me consider giving BSD a test run on one of my computer. It appears to have some interresting posibilities. And it should be worth getting to know better, it could be the right tool (OS) for some types of "jobs".
The problem is always where to start, I assume there is no BSD flavor as easy to install as Mandrake (just to pick one), but then I am a happy user of Debian (2.2) floppy installer. A few hints to start out on, for instance a install/easy of use comparison of the various BSD's would probably be helpful to more than a few readers.
Carbon based humanoid in training.
...Microsoft's goal has been to add more saleable features and more handcuffs for their users. Bill has a moneymaking mania. Then they expect a month of bugfixing to make up for over 100 months of bugmaking.
OpenBSD, on the other hand, probably has 100 months of bugfixing up its collective sleeve. I wonder if they expect that a month of portting applications will make them more popular? (-:
IRL, a month of porting applications would simply mean an order of magnitude more security holes to fix.
Making OpenBSD completely thread-safe in preparation for multi-CPU stuff is probably a steep hill to climb, too. However, the kind of stuff that OpenBSD does well probably means that very few single-CPU OpenBSD machines will be CPU-starved until long after they're disk-I/O or net-bandwidth-saturated. Which means that it makes more sense to cluster than to proliferate CPUs in an already-saturated environment.
Got time? Spend some of it coding or testing
I think finally I am gonna try OpenBSD. Does anyone know what hardware requirements it has and what are it's strengths as a server and as a multimedia desktop for home/office user ?
/., this was interesting:
3 332
Also on
http://slashdot.org/comments.pl?sid=52272&cid=519
Anyone mind explaining, or posting some links to pages explaining, what stack smashing is, and why an executable stack stops it?
We're not all l33t haxx0rs here...
"Upon attaching the waterblock to my penis, I began to notice that I know nothing about computers." -- JRockway
I prefer to use BSD (Free* or Open*) as servers, as opposed to Linux.
Why?
If you've ever installed a Linux distribution, you will immediately note the number of third-party libraries and applications installed on a 'base' system. This is frustrating for me, because for the most part I may not want all those extra applications installed, because it clutters up the system, and there may be various vulnerabilities present that I'll be open to.
Instead I prefer to use BSD in these situations, because when you install the operating system, everything with a few choice exceptions (ie, gcc, apache, less) everything is part of the BSD operating system, no third party apps are installed unless you choose to at install time.
So when I install a BSD server, its clean from the get go. If I want bash, I have to install the package. This way I get control over what is on my system, and spend far less time adding what I want, instead of removing what I don't want (in the case of a Linux distro).
I use MacOS X laptop, which is the vision for what I always wanted my linux desktop systems to be. I can play DVD's, get sound working, simple updates, bash, gcc, ircII, web browsers which don't have problems on most sites, beautiful MP3 application, mail, etc.
For me, I don't even bother with Linux except for testing program portability, or for wireless lan-related applications (airsnort).
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
I want it now, but I'd whine if it weren't fully tested. Man, to think I'm doing the "gotta go pee" dance over something like this. I need a life.
We have a lot of single-purpose OBSD boxen here. I like them a lot. Go, team, go!
Say goodbye to JVMs which do on the fly instruction creation. Can this OpenBSD page protect mumbo jumbo be set on a program by program basis?
I never did understand why this particular set of problems was allowed to exist on most x86 UNIX-like operating systems.
It's too bad that they weren't able to completely seperate executable and readable memory, but it's good to see somebody finally taking these problems seriously.
And as a bonus to making the system more secure, these changes will make it easier to debug stack-smashing bugs.
-Mark
TROLL. as if "A non-executable stack is one of our own innovations" doesn't give it away
Theo de Raadt writes:
If you're running a JIT compiler/interpreter or other dynamic code assembly, you sure as hell do.
I can see how you might be able to write dynamically generated code to a page, then turn off PROT_WRITE and turn on PROT_EXEC before jumping to it. However, this is almost certainly two trips into the kernel, each involving tons of permission checking. So performance will likely suffer, which negates the whole point of doing JIT in the first place.
I like his survey of MMU architectures, though.
Schwab
Editor, A1-AAA AmeriCaptions
Can anyone explain to the idiot what a non executable stackmeans?
Anyone know how portable these modifications are to other BSDs, notably Darwin?
I found the meaning of life the other day, but I had write-only access.
I ask this because I once got in trouble for accessing a webserver 60,000 times over night. This was over a considerable amount of time (about 13 hours) yet it was called a DoS attack. I simply called for a web page using PHP's fopen and a while loop. Unless this really wasn't a DoS, I don't see how you could prevent something like that.
SIGFAULT
Ancient and venerable 24-bit CDC 3150 machine in 1970 solved buffer overflow problems by pre-writing return jump to execover (pass control to data area and bang, you're dumped) instruction throughout user space. When you got the dump, the ASCII interpretation was "ojoy". So you got about thirty pages of blue-bar printout saying "ojoyojoyojoyojoy...".
Thou hast damnable iteration, and art indeed able to corrupt a saint - Henry IV, Act I scene II
Theo de Raadt spells his name like i just did, not "DeRaadt" (see article from story). besides, this is blatant troll. mod down.
How can the Propolice feature do its job without compiler support - i.e., at compile time? Surely there is not enough information in the ELF executable to differentiate variables and buffers once the executable has been stripped. What am I missing?
Theo's description of Propolice:
Propolice is, as I like say describe it, "Stackgaurd on steriods".
Stackgaurd uses a random canary (random value constant per run)
placed by the function prologue and checked by the function epilogues
to ensure the return address has not been moved. It was i386 only
code. Propolice is machine independent, running on most of our
architectures. As well, Propolice rearranges variables inside a
stack frame so that the ones most likely to overflow (ie buffers) are
closest to the canary, thereby making it hard to overwrite pointers or
regular integers (which it moves down).
..but it seems OpenBSD is refusing to die.
The floppy based install is pretty easy. If you have a windows nt/2000 box, get ntrw.exe and (probably) floppy32.fs. run command ntrw.exe floppy32.fs to create a boot floppy. If you have a weird device, you may need a different .fs file, read the docs...
/tmp, /var, /home, but this is a simple example) The first partition is always / (at least, I can't make the installer do anything else- correct me...) and the next is the swap partition. Something like 2*RAM should do for swap (again...correct me if I'm wrong)
It does put you in a disk partition situation which can freak people out. For your first experiment on a disk with no data you care about, you can tell it to use the whole disk for obsd, and go with two partitions. (many would advise separate partitions for
If you can set up an ftp server, you might want to get the ~120MB (if using X, about half that if not) and put it on a local ftp server. I have found the mirrors pretty adequate, even right after a new release.
Post an obfuscated email and I'll send you a cheat-sheet, with how to do common things that are too easy for the gurus to think of supplying and too hard for a novice like me to figure out. Mostly network stuff.
A nonexecutable stack is no guarantee of safety. Solaris 2.6 demonstrated this here.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
The OpenBSD team is a really great group of hard-working coders that don't stop with writing just average code.
This latest security measure goes to show why they're still #1 when it comes to really closing up a machine's holes to prevent abuse and unwanted infiltration into a system.
Unfortunately, they still can't get UltraSparcIII documentation that they need for their project.
I urge you all to contact SUN Microsystems and demand that they hand over the details of the US III series computers.
*nix.org -- Latest article > "Taming OS X"
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
I don't think anyone claims OpenBSD is not an innovator. But it really isn't that hard to secure a *nix box from most security breaches. The biggest part is keeping current on patches and staying away from software such as BIND and sendmail. I can still exploit root on an OpenBSD machine with a crappy CGI. If you need to hack the data on a machine, there are low level exploits (though if you have data someone would want to hack, you should be encrypting your filesystems.)
:)
I do admire OpenBSD's approach to software development; it can be called responsible if nothing else. It's just that for volunteers who basically code other *nix OSes, code auditing is not nearly as much fun as porting your OS to a Nintendo.
VMS is probably a close second in terms of security. Its C-2 secure right out of the box. Plus most script kiddies would be left scratching their head trying to use it.
Only the State obtains its revenue by coercion. - Murray Rothbard
I would argue that a JIT compiler isn't a "Normal Unix process", the way that Theo's using the term. A debugger wouldn't be either, among other things.
But your http server, and your inetd, don't need to write code into their own address space...
-Mark
joeb ruin spells his name like i just did, not "joe bruin" (see article from story). besides, this is blatant troll. mod down.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Most web hosting companies use BSD for shared servers. BSD is more secure.
Most 'Nix desktops and programmer workstations run Linux. Linux is friendlier, has commerical backing, and has a bunch of companies that put it out on "20 minute install and go" distros. Other then that, both operating systems are equal, can perform the same tasks, are flexible, and better then the immoral alternative.
The middle ground is a joyous place. Let's just hope that both projects continue to grow and prosper. Two choises are better then one. Both causes fight for what's right.
I really never understood all of the bickering.
That sounds like an Onion headline.
You just have to explicitly mprotect(2) the memory where it happen with PROT_EXEC|PROT_WRITE. The fact that on some OSes it can work without doing that is actually a bug in these OSes.
What the change is doing is the right thing, using a minimum privilege way to achieve more security. If some static code actually contain data that look like machine code it could be executed this wont be possible anymore.
Non executable stack by itself was far from enough as most program have some way of putting things on the heap or elsewere for an attacker and he could jump there instead of jumping on the stack. Coding an exploit for OpenBSD will get real tough now, even if there's an actual buffer overflow.
I often hear glowing praise such as this for OpenBSD. Why do we have two different Open Source groups working at seemingly common purposes? Or is it (for you Monty Python fans) a case of the PFJ vs. the PJF splitters?
Alas, in this day and age, the latter is becoming increasingly vital. Look at the advisories we're getting nowadays -- insecure handling of URLs coming from the outside world via email; improper quoting; ... -- all in stuff that doesn't listen directly to the outside world.
It is better by far that an application be designed from the ground up to be secure, and to restrict its parameters to known-safe values, than to try to tack on security as an after-thought. You don't know how a given piece of code will be used in the field. Making sure that it fails in a known safe manner is essential, because you don't know when it might be used in a place where failing in a random fashion could cause an intruder to gain unauthorised access.
The days of the Internet as a warm, fuzzy, safe place are over. The days when the desktop computer sat on its own, and didn't interact with any other system, are also pretty much over. Times have changed; attitudes towards programming must change with them, or security problems will only get worse. Far worse.
As for the comment that you can exploit root on an OpenBSD box with a crappy CGI -- yes, this is true. That's exactly what I'm getting at with my comments above. OpenBSD's goal is to produce a system that is secure from time zero. In other words, you can install OpenBSD, stick the box on the Internet, and feel reasonably sure that it won't get hacked before you have a chance to close any holes. Anything that you add to the system is your responsibility, not the OpenBSD team's.
Seriously, without MS would there be a reported "shortage of qualified computer personnel"?
If all these exploits are beaten before they are even implemented how will one prove their worth to their employers?
Damn it, I thought that SQL Slammer was a saving grace. We didn't have our servers at sp3 but then again they are behind a dual stage firewall so we had no hicup at all. However, I got the time at work to install patches as a result of the media.
To summarize: don't eliminate vunerabilities because you'll just be eliminating someones job (both the admins and hackers).
[end sarcasm, or my attempt at sarcasm since I haven't seen any around these parts since 1995]
What is done is protecting memory zones created by the linker, mostly memory zone holding constants and static variables, so no there's no executable code in this area.
When you write a JIT you allocate your own memory on the heap and then compile your code there. On order for this code to be executable you have to mprotect(2) the memory zone holding your code with the PROT_EXEC flag, or PROT_EXEC | PROT_WRITE if you want to be able to modify it afterward. Anyway you can change the memory protection at anytime so anything you could do before you still can do.
Secondly, who the hell are you? Stop impersonating me on Slashdot.
--
Theo de Raadt
Founder, OpenBSD project
What's a lamen?
Real Programmers write in FORTRAN.
Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.
Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster --- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)
I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.
"If a program can't rewrite its own code",
he asked, "what good is it?"
Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.
Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.
In modern parlance,
every single instruction was followed by a GO TO!
Put *that* in Pascal's pipe and smoke it.
Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.
"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".
It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just *past* the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".
After he finished the blackjack program
and got it to run
("Even the initializer is optimized",
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.
Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.
After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.
I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.
Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. *None*.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.
The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.
Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account ---
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.
The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on ---
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.
He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.
I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.
When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer.
-by Ed Nather, on May 21, 1983.
Clueless : Informed
--
est modus in rebus
During these hostile and trying times and what-not, OpenBSD may your family's only line of defense! Only line of def-def-def...Only line of def-def-de-df-df-df-df!
:-)
Be sure to download the openBSD theme songs if you haven't already.
La Temperanza : Sense of humour enabled individual
If volunteers in an open source project can make an operating so secure, why can't a company with a lot more money and programmers not secure their operating system as good?
-Fzz
How can they have the gall to call BSD secure, when it doesn't even implement standard DRM measures? Secure for who? Would-be thieves? I question the intentions of someone ('Theo' or is it Teddy?) who has used a sort of extreme relativism to call such a thing 'secure'.
I guess you could say, we are working on things more significant and important than making sure OpenBSD works on crusty old PDP-8s and Nintendos
:P
Well don't lose sleep over it, I pretty sure NetBSD tied up those loose ends LOOOOONG ago.
Join the TWIT army now!
Don't forget about Mac OS X. It is BSD, but ease of use is an order of magnitude greater than anything else out there.
Someone in FreeBSD and NetBSD with commit priviledges is surely looking at those patches.
...but he mentions 3.4. I think alot of us were hoping these features would make it into 3.3.
The meme police, They live inside of my head
The bigger problem is that the principle of least privilege is not adhered to in world of Unix. Programmers will always write bugs and applications will always have vulnerabilities that can be manipulated. Manipulation of services should only effect the service being manipulated, not the whole system. For example, services should have NO access to anything by default. When you install a service you should set up the specific permissions that it requires (this can be made easy - the app, upon install, can recommend the permissions and you can just say, "okay"). If the app tries to do something that it doesn't normally need to do (like access /home/me/mysecretfile), the system should log an access denied message; the Linux kernel right now can't even audit denied access to files! CHUID permissions to deliver mail to people? A much cleaner mechanism is for the mail server to create the files under its own name and give permission to the user to take ownership of the files.
Linux, and Unix in general, tends to have pretty limited access controls. Even with ACL support, the distros still need to ship with restrictive settings and manage them. A lot can be done to provide a framework under which compromises can be limited and can be audited. Right now we don't have that. Without detection and reaction, how do you know that your prevention is effective?
s/Lousy Security/Lousy Interface + Lousy Security/
Just what the subject says.
openbsd will never be as secure as things like selinux, rsbac, grsecutity etc. these things give a ling needed overhaul to the permission structure, and theo(foolishly) says this is what users dont need. hence no need for obsd, when linux offers everything, and can be made more secure than openbsd.
Any extra help you might be willing to offer with these systems would be greatly appreciated.
wbudell at alief period isd period tenet period edu
Sorry it's a long one. For anything sent, many thanks.
wb
BSD is dead? Insightful? Sounds like a troll to me considering today's article re: Mac OS X and Linux.
The meme police, They live inside of my head
Even more gay! Homsexuals, fudgepackers, and slashdotters rejoice!
From the article itself:
[[[
These exploits require a high degree of precision. I've tried to take out most of the guesswork, but there are two things that might cause the exploits to fail. The lpstat and rdist exploits expect certain things to be in the environment at exact locations.
]]]
Probably the best metaphor here is the game Twister. The new work by Theo et al. forces the black hat to put his left elbow on the blue bubble. Sure, he can still do something devious with his right leg. But if Theo keeps dealing out the cards, eventually his bowels will explode.
In constructive software development, the programming cost is widely regarded as exponential in the number of constraints faced. Yet in the popular lore, for a black hat, a sliver of a glimmer of a faint and twisted hope is all in a day's work. This from the lips of the same people who pretend not to believe in Area 51.
Don't get me wrong; there's nothing wrong with a hobby. Everybody should have one which they enjoy. But realistically, OpenBSD is more than quite a few furlongs out of the running when it comes to impacting the IT industry. It is a shame to squander time on a terrible dead end and waste of resources, energy which would be better spent working on something which is actually used.
You're statistics are clearly based on number of reported vulnerabilities; unreported vulnerabilites of Windows versus *BSD or any flavor of UNIX for that matter is quite a staggering ratio.
By the way, this isn't the first time OpenBSD has cracked down on security bugs; they've been doing it since the inception date. Read their mission statement, then their mailing lists.
If they'll just get off of their butts and get SMP support, I'd switch all of my servers over to it in a week. Really. It's just too bad that they don't seem to want to support anything larger than a desktop PC.
Wait, my desktop is a dual Athlon. I guess my DESKTOP machine is just too advanced for them. C'mon, Theo, get it together.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Well, like I say, there is nothing more American than a good ol' fashioned double-standard.
Manipulate the moderator system! Mod someone as "overrated" today.
OpenBSD, and BSD in general is so much more secure than any version of Windows, it's laughable to even compare the two. This isn't about tightening up their own code, this is about tightening their code to prevent poorly-written 3rd-party applications from becoming launching platforms for attacks against OpenBSD machines. Microsoft's main problem with security isn't 3rd part apps, it's the millions of lines of unsecure and buggy code in highly integrated applications such as Internet Explorer and Windows Media Player.
To compare this to Trusted Computing is like comparing apples and black holes.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
Forget about security through obscurity, this is security through paranoia. Sometimes, it is justified.
Will W^X disable all runtime decrypting/decompressing binaries? It seems to me that these features prevent burneye and/or UPX style binaries. Thoughts?
Chris
Lets ignore the fact that MS basically put ALL their products on hold to do this, and released a swarm of patches to fix problems they found.
;-)
Not very effective were they?
A swarm of patches that Microsoft itself can't patch its own computers?
For some years, OpenBSD has had the annoying habit of closing holes about six months before the exploits are discovered. It's called being proactive
MS nominally put their products on hold for a month, but that is all. The OpenBSD design philosopy is paranoid - Microsoft need to have the same for their core components, and to make sure that other layers can't just quietly bypass security measures for performance.
A fast webserver doesn't really do you much good if it is 0wn3d by some H4k0rz. The wird thing is that the underlying security mechanisms (identifiers, rights and objects)in NT/2K are really quite good. Regrettably, usability sucks and support for the security mechanisms by applications (especially Microsoft's own) was non-existant. Once you have busted an app with "Functions as part of the operating system", you own the kernel.
Personally, I believe in plurality and I like spreading an app between different Linux dists, FreeBSD or OpenBSD. I would also include Win2K on thatm except that essentially you pay based on connections, which can make it really pricey. However, the idea is that one system may be broken into, but not all.
Facing the external internet though, I still prefer OpenBSD.
There's a general consensus that it's an excellent server, especially for anything in a DMZ/outside firewall. A minority use it for workstation. It'd be a pretty secure workstation, though. I've not taken it that far.
The hell you can! Apache is running as a normal user, and is chrooted. In addition, systrace is quite popular, which could be used to stop even horrible applications which reqire root access from being exploited even in case of serious bugs.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
No. People are praising one group of developers who have been paying extremely close attention to security issues for years because they've released yet another useful to deal with a potential exploit.
On the other hand, people are lampooning M$ for pretending that one measly month of developer work to will address security problems they've been introducing into their application software for years. Really, it's little more than a Band-Aid(tm) to assuage the fears of CIOs.
For what it's worth, Microsoft has it's own very serious local privilege escalation security hole which may not even be possible to fix because it's partially due to a serious design flaw. Read more about it here. (How to "shatter" Windows... funny, eh?
It's exactly that kind of gaping security hole that the OpenBSD developers work so hard to avoid. That's why they are praiseworthy, and why we scoff at Microsoft's belated efforts to patch up security issues that should have been accounted for from the very start.
BSD has no,zero,zilch worthwhile security.
;)
If it does, then how did Theo crack the system in the Nakatomi building? If BSD had been secure, John McClane never would have had to take on those criminals by himself.
Winky added for the humor impaired.
I belive it was BSD 9 in a screen shot of the computer. After much deliberation, I have decided NOT to play Die Hard to be sure that was the correct version that was displayed.
The Kruger Dunning explains most post on
Thank you OpenBSD!
Cleara
How many people use it? 100, 200, maybe 300 tops. BSD as a whole has lost. And OpenBSD may be the the biggest loser of them all. If you gave an OpenBSD convention, the only vendor to show up would be the pizza delivery guy bringing everyone lunch.
On Intel processors, read- and execute-permission for a memory page is only one flag. For this reason, if you make the stack nonexec on Intel machines, the cpu will have to do a lot of context-switching, because all the protection faults that occur when an application tries to read from a non-exec page need to be handled by the OS kernel.
On SPARC, Alpha or POWER CPUs there is one flag for the read-permission and another one for the execute-permission.
To prevent exploitation of buffer overflows, I believe that we simply need much better hardware.
For example, IBM's AS/400 has Hardware pointer protection. It is absolutely impossible to fake certain types of pointers on the AS/400, because the CPU will recognize when a pointer has been overwritten due to a buffer overflow.
That's how REAL bufferoverflow-protection works. If you just make dataregions nonexecutable, you can still parameterize some kind of library function (how about execve()?) and make the vulnerable program jump into the codesegment to execute the library function with the parameters specified by the attacker.
AS/400s simply 'abuse' one bit in the ECC code as a flag for marking valid pointers.
For every 64 bits in RAM there should be 1 flag bit, which tells the CPU whether the data in memory is a valid pointer or not.
An instruction like LEA (Load effective address) should then implicitly set the flag, and instructions like MOV (Move Data, actually a copy instruction) should always clear the flag.
If a RET (return from subroutine) instruction tries to load an unflagged (=invalid) pointer, the CPU should trap to the OS kernel.
For legacy application, that are too damn stupid to use pointers in a correct way, a privilege could be added to the OS kernel to allow an application to use even invalid pointers.
Furthermore, read- and execute-permission should be separate flags and all stack- and heap-pages should be nonexec by default.
pers.
While my dsl connection is down due to a dmca takedown notice, I decided I'd mix it up a bit. I'm currently running strictly gnu/linux, with individual firewalls on each box with public ips, and a linkie doing nat for the workstations.
I figured with the downtime, I might as well try out Debian (although reiserfs looks like a pain) on one box, FreeBSD on a second, and OpenBSD on a third. Since I'm going to be adding web pages for other users for the first time, and granting access priveledges to the users, I thought I'd get my act together and do it right. Use OpenBSD for my software firewall, behind my router that also has firewall abilities. Software router? Choose the best of course, OpenBSD.
So I download the necessary forms to fax over to cheapbytes to get the FreeBSD discs, the OpenBSD official set, Slackware (always wanted to try it for the hell of it, and I need the all-around experience), and Debian (where the hell are those Debian ISOs on the web site guys?). Anyway, I've ordered from Cheapbytes before, and am always happy ordering from them (though the shipping could be a buck or two cheaper at every weight level).
Prior to faxing the order though, I decide to check the OpenBSD web site to make sure I'm getting the latest distro (something you have to watch at Cheapbytes, but this is more of a book issue than a disc issue).
Low and behold, I can't connect to Openbsd.org (again). Tried all day. I'll admit, while my dsl connection is down (thanks Jack!), I'm accessing the site through a relative's aol dial up account (are all aol users banned from OpenBSD.org?) But I am also using Mozilla (minimizing aol client) to access the site, and nothing.
So I do a google, and I get an OpenBSD message board at another web site. Don't recall which one, but it links to OnLamp:Patching OpenBSD (5 or 10 article series) on the front page, lower right hand side. So I start looking at the messages, and every message is a flame war between individuals, with terms of weenie, dickhead, moron, asshole, and more.
Is this what I can expect from the OpenBSD community? Is this standard operating procedure?
I decided to stick with the hardware firewall solution for now. Next time I go to an installfest I'll cop an iso image of OpenBSD. Or not. But I'll definitely look into this idiotic behavior more before I decide to pay for an official distro.
I still haven't settled on a distro (gnu/linux) that I'll be comfortable with. My guess is that it will be either Debian or possibly FreeBSD. So far, all my testing has been on Cheapbyte CDs, or what I've received at installfests. I did finally buckle and split an official professional set of SUSE, as that's what I'm using on most servers now.
For all those out there crying about freeloaders, think about this: I, and most others, haven't settled on a distribution that we know we are going to stick with. I've tried Mandrake, Red Hat, and am running SUSE. I've also tried older versions of Slackware. They have almost all been on Cheapbytes discs, or copies of others disks.
Once I settle on a distro, I know that I'll be buying the official set, as I want the manuals, and I support those that help me. Slackware will be one official set that I'll be ordering, as I know that I'll be using it on at least one box at all times, and I'll be using it on boxes with older hardware. FreeBSD or Debian will be the main os I'll be using for my production servers, and I'll also be ordering official sets from them. That leaves OpenBSD. Will I, or won't I be using it for my firewall/chrooted apache setups/outside user access to the servers setups? If I can get a handle on OpenBSD, and the developer(s) have nothing to do with the stupidity on the message boards, yeah, I'll be buying an official distro. And like in the case of Slackware, where the official distros are nominal money (as compared to other distros), I'll also be purchasing other items such as mugs, penguins, steins, or whatever, as long as I know that the proceeds are going towards developers who will be providing me with software that helps me get the job done. This is coming from someone who's annual income has been less than $10,000 for the last several years, and doesn't look any better in the forseable future.
The money may not be coming from users yet because they are purchasing Cheapbytes or downloading iso images for distros that they are testing. A lot of people I know have more than one distro installed on more than one box, and are constantly experimenting with different distros because they don't know what they like yet. Once they settle down (and once we stop seeing releases every 5-6 months) more money should start flowing to the distro "owners".
So, anyway, is the childish stupidity seen on the OpenBSD board I was looking at a normal occurance? Is this what I can expect from the OpenBSD community?
Gosh, don't you just hate that? I do too, that is why I only run my servers off the Debian root floppy. With five virtual terminals, who needs a base system or other stuff from "third-parties"? Why should I let this GNU stuff get between my server and pure Linux kernel goodness?
Joke over. Here is a little story about the development of BSD. It kind of looks like other free software develoment, where lots of "third-parties" throw in their useful contributions. I'll admit that some distros are getting a little bloated but that's no reason to be nasty about things. OpenBSD is a nice, easy to use and secure dist.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
Where is OpenBSD's SQL-speaking relational database server?
can't install it on my main production servers. Why? Because it STILL does not have locales. And without locales cyrillic doesn't work in mysql, zope and other applications :( OpenBSD makes a great private net forwarder in remote locations tho.
"Fact: *BSD is dying"
Ok, might be, but it is one tough motherfucker and hasn't stopped kicking and screaming. It's rather resilient like you trolls. I'd figure BSD will be dead about the same time you trolls take the stick out of your ass. As you can feel that bad-ass sucker poking your rectum like some monument to sadism, you will know that it is firmly implanted, and isn't coming out soon. So *BSD yet lives!
Too bad the Open Source community has no equivalent...
May we never see th
Trusted Solaris
andPit Bull from Argus Systems
IIRC, these are more common Un*ces that are patched to provide "capabilities" - that is, instead of the root being the one-size-fits-all user that has enough privileges to get anything done, different kinds of access are broken down so that if a running program getw 0wned, it limits the damage.
Theo's answer to that probably would be, "code it right in the first place and it won't GET 0wned!!!", which is a valid point, the devil (no pun intended) is in the details.
BTW, I first came across EROS comes from Alan Cox in an interview with Robert Metcalfe a few years ago (remember the "Open Sores" series of articles? Great trolling, Bob!), in response to a question of what he thought was going to be the next big thing after Linux. He was impressed with the response (having previously accused Linux-y types of monomaniacal zeal), but it didn't overturn his opinion at the time that Linux was doomed. Oh well. (This comes to you courtesy of the similarly fated Internet.)
It would help if they stopped IRCing from their CVS repository machines. That may not make their code more secure, but it will help keep the back doors and trojans out.
I am constantly amazed that people who commit this kind of beginner's mistake have the gall to call their software "secure". And then they ship sendmail and BIND with it. ROTFL
And then they ship sendmail and BIND with it.
The BIND that comes with OpenBSD is an audited V 4.x IIRC. That should suffice for many many users, those that need 8.x or 9.x can find it them the ports tree. The sendmail is locked down as well and doesn't accept connections by default.
Nice FUD otherwise.
Trolling is a art,
actually no, fuck you!
Lots of responses, too. Nice work!
Let's collectively feel sorry for this guy.
Mao was right, you were utterly wrong. Enjoy.
I was thinking about this on my drive into work this morning, and I came to the conclusion that what we need to do is to change the C style stack usage to use two or three stacks.
Consider: C uses the stack for three types of information: call/return information, parameter passing, and local variable storage. I assert that this is the cause of most of the stack problems in C - you are using the same thing for three different needs.
Let me discuss each of the three uses in turn. I will use x86 terminology for this discussion because that is the primary architecture used for Linux and because that is what I am most familiar with, but you should be able to generalize my points without much problem.
First, you have the call/return stack. This needs to the be CPU stack so that normal CALL/RET operations work. The only things that should be stored here are the actual return addresses, as well as possibly register saves (esp. for interrupt routines). However, in a unified stack design it is possible for the bad guys to modify the return address. Thus, even in a non-executable stack environment I can still change the return address to point to a function, say exec().
Second, you have the parameter passing stack. Ideally the only thing on this stack would be parameters passed down to the function from the caller. However, in a unified stack design, I can modify this stack to contain data - thus I can create a pointer to the string "/bin/bash" on the stack. With this and with the call/return modification above, I can cause the current function to "return" to exec(), with "/bin/bash" as the arg. Boom. Remote shell.
Third, you have local variable storage. If this space were seperate from the other two stacks, then overflowing a local buffer, while still bad, would not be able to modify the return address nor would it be able to create parameters. Ideally, every subroutine would be given its own sparely mapped local space - thus boundary errors would likely throw a page fault (granted, the cost of setting such a mapping up for each subroutine call would be prohibitive, so it is unlikely to happen without some form of hardware acceleration. Perhaps a low/high limit register could be added to the various index functions, such that an access relative to EBP, ESI, EDI would fault if it went out of range.)
However, consider just seperating the stack into three areas, widely seperated. ESP would point to the hardware stack. EBP to the local storage area, and ESI to the parameter block (with EDI pointing to "this" for C++). Now, a bad programmer has a buffer in local storage and doesn't range check it. A would-be exploiter still cannot modify the return address nor can he modify the parameter stack. The most he could do would be to hose the local variable storage (granted, that might still allow him to corrupt the local vars for some other function and perhaps get an exploit that way, but it would be even more difficult).
Granted, to do what I just suggested means throwing out *all* standard libraries, tools, compilers, and so forth - I am not actually suggesting that the x86 family do this! However, for new architectures like Sledgehammer et. al, this might be the time to make such a break.
www.eFax.com are spammers
OpenBFD
PegQuin--I've got a sneakin' suspicion
Perhaps isn't their concentration about security just a propaganda?
Of course it is. It is a well-known fact that Theo works for Red Hat and Niels works for Suse. Their employment makes them used to working on insecure OSes.
[/sarcasm]
I missed the parent, but you make it sound as if X doesn't run on OpenBSD. I used to run KDE on my laptop with OpenBSD...
I can still exploit root on an OpenBSD machine with a crappy CGI.
/var/www] (httpd)
Really?
www 2224 0.0 0.0 1188 1760 ?? Ss 7:01PM 0:02.24 httpd: parent [chroot
But it doesn't run as root and it's chroot'd...
Good luck getting root!
I think by far the easiest way to mitigate the security nightmare that buffer overflows represent is to use LIDS (www.lids.org). Buffer overflows would not be the huge problem that they are if you didn't have daemons running with all of the privilidges of the root account.
/usr/sbin/httpd the ability to bind to port 80, and no other root powers.
LIDS lets you strip away all of root's power, until it is no more powerful than any other normal user account, and add individual capabilities back to particular programs, like giving
Now, buffer overflows are still a problem in that you can crash a daemon, but they would not be the security disasters they currently are.
What I like the best about LIDS is that is sits on top of the existing Linux security mechanisms so nicely and doesn't do violence to them. You can turn off LIDS when you need to install new software or want to test something without having to figure out a whole new ruleset. You just disable it, do your testing and reconfiguration, then reenable it before you go back into production mode.
Niels isn't an OpenBSD developer anymore.
He is a NetBSD developer now.
Kernels (except OpenBSD now) assume that PROC_READ automatically means PROT_EXEC. This violates the POSIX standard. I'd consider that a bug.
openbsd idea doesn't look very original, try to look at http://pageexec.virtualave.net/ , you'll find something similar developed over a couple of years. granted, it's for linux and x86, but sparc64 port should be ready soon. it is a substantial part of http://grsecurity.net/ . openbsd lacks a lot of features, that's why it's suitable only for a few specific tasks.
Anyone with a brain can see there is nothing MS can do about bad programming that third party apps do.
so go scoff at something you know something about. BSD also doesnt have the ability to run 99% of the software that Windows can. Makes it much simpler to maintain, doesnt it?
Manipulate the moderator system! Mod someone as "overrated" today.
I should make my sig "Slashdot: News for Linux, complaints about Microsoft, Stuff that is irrelevant (unless you use Linux, Mac, BSD, etc)", because that is what this place basically is.
Oh well, I guess there is nothing more annoying to a hypocrit than having someone say "Youre a stinkin Hypocrit".
Have a nice day.
Manipulate the moderator system! Mod someone as "overrated" today.
Lets all get one thing straight- the only secure computer is one that is turned off in a locked room. ALL the OS's out there basically suck. Some may just suck a bit less.
If you think about it, MS is in a difficult position- they cant have non-technical (or the hordes of fake technical) people complain that things wont work, they have to provide a platform that is easy for other companies to write programs for, and they have to make everything secure.
ANY security decision requires a restriction on ease-of-use. This is true of door locks, automobiles, computers, telephones, etc. I will admit, and even complain, that a lot of things that MS has implimented were cludgy, based on old crappy politically contrarian past decisions, but MS has done more to innovate computer usage in the last eight years than ANYONE else.
Can someone get some stats on computer sales before and after the release of Win95? This was truly the first OS to tie it all together. Was it perfect? No. But its easy to sit here in 2003 and knock the decisions made in 1995; we learned the lessons from things that they pioneered.
Is MS perfect? No. But two friends of mine went an got jobs there, and they were basically two of the best computer people I have ever met. And also, the MS people that I occasionally meet in my job are likewise very hardworking, knowledgable people.
So sit in your chair with your attitude of inflated superiority. Its probably the only thing you have. I personally think its rude to knock people who have a tough job, and are doing very well at it.
Manipulate the moderator system! Mod someone as "overrated" today.
In the Good Old Days (TM) there were machines like Burroughs 6000 and Symbolics 3600 that had tagged memory architectures. Each word had non-data bits that defined the contents of the word. Some of the bits were used for garbage collection. On the Burroughs machines there were data descriptors that defined the length of arrays, so that it was impossible to index outside the array storage. There kinds of architectures are very reliable. Rumor has it that the U.S. government still maintains a significant number of Symbolics machines because they have not found a replacement that has the same reliability, even though the Symbolics software has been ported to current generation processors. Given the number of transistors that are packed into current CPUs, and the cheapness of memory, it is a real crime that this kind of architectural features are not a part of any current CPUs. (Note: I worked on development of the B5900 and used Symbolics workstations, so this is not just hearsay.)
Trustin' in the security of OpenBSD is not a strategy, and it is not an option.
Trustin' in the security of OpenBSD is not a strategy, and it is not an option....
typedef u_int32_t uid_t;
% uname -mr
3.2 i386
OpenBSD does support 32 bits UIDs and always has. off_t is 64 bits and always has too. Linux is the OS with grow problems, decent OSes are sized correctly from the start.
On one hand, there were... how many million lines of code in Windows at last count?
On the other, a heck of a lot of `Linux' stuff recompiles painlessly for any of the BSDs. All OpenBSD really needs is a nifty installer - and it could borrow one from Debian, soon.
Got time? Spend some of it coding or testing
The BIND that comes with OpenBSD is an audited V 4.x IIRC. That should suffice for many many users, those that need 8.x or 9.x can find it them the ports tree. The sendmail is locked down as well and doesn't accept connections by default.
Why ship with BIND and Sendmail when they are known to be buggy and insecure? There are alternatives available that are secure (such as qmail and djbdns). So Sendmail is OK if you never need to accept mail? What if you actually want to accept mail?
Nice FUD otherwise.
Then explain how this happened.
For that matter I doubt you could hack me through the CVS version of IrcII-EPIC even if I were running as root, and I'm running gentoo linux, not even openbsd.
Remember, OpenBSD isn't just about avoid remote root holes, they fix local ones as well. Fixing local holes means that even if you do manage to execute commands through someone's irc client you still are unlikely to be able to root the system.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Sometimes it gets placed on the stack cause it is easy to do that when you are programming the JVM in C.
:)
But a JVM will never be fast as long as it is written in C...
Our JVM allocates memory for each object and stores the code and data together... interesting things can happen when you write this all in assembly.
We may not finish for 50 years, but ohh well
use a PGP sig or something. or are you also an impostor?
This was one thing when an OS cost $50, but it isn't really excusable when you have a $5000+ system.
I know how it happened, the engineers were told to go off and produce wonderous things but there was no overriding concept. Once those things were produced they had to have the software equivalent of a file and hammer to fit them together.
Did MS innovate? Well no not really. A lot of what MS came up with is based on technology acquired from other companies. Some of the stuff they have produced has been very good, i.e., the Win2K kernel, but there is a lot of rubbish around it that isn't. It is that rubbish, incidentally that is hard to configure and either crashes or lets the intruders in.
I have worked on some big closed source projects, one as big as Win 2K with over 30 million LOC in the backend alone. It works quite well and is quite secure, despite being written in a hodge-podge of languages and having spanned 5 architectures. It just takes a lot of work and something called QA.
Lastly, I don't have a chair of inflated superiority because I don't dance in the clouds with the developers. I generally end up with my feet firmly on the ground having to work with the things and to promise clients that they are not going to be down. I don't really care about what is put in front of me, but I prefer it when I can look at the source to figure out why it is going wrong. MS is at a disadvantage there.
Scott Kamp
Founder The MicroBSD Project
We have been perusing the OpenBSD mailing list, and also an article found on deadly.org pertaining to the newer security features in OpenBSD. While alot of the features are new to OpenBSD, they are not new to BSD itself. The MicroBSD project integrated stack-protection into its 0.1 release back in 2001. The integration was done by Hiroaki Itoh on our servers in early 2001. While we have tried to clear the record and provide the correct information to the BSD users, both through www.deadly.org and slashdot.org the submitted
articles were rejected. A direct email from the deadly.org site quoted it as sheer flamebait,and untrue.
Well,we know differently and intend to only set the record straight. This almost seemed as
though MicroBSD information was being censored, yet the clear facts still stand as they are.
When it comes to "Stack Protection" capabilities we not only released it in MicroBSD 0.1, we were the first BSD to do so. We are not looking to start a flame war, but the acceptance of truth and the reliazation that OpenBSD is not the forefront of certain capabilities and technologies. And there are others with "Vision". The article which includes an email that was posted to the OpenBSD misc mailing list. Specifically the context thereof containing these two phrases
"The most amazing thing about this new buffer overflow stuff is that it appears noone in any other project has commented on it in a public
mailing list anywhere. Eerie silence."
"I don't know about how you guys view that, but to me it is pretty depressing that none of these other projects (or their users) see the
impact and import of these changes; that indicates a large lack of vision."
New, maybe to OpenBSD itself. But not to the BSD world overall. Im not looking to start a flame war or anything here, but the MicroBSD project at
http://www.microbsd.net is actually the first BSD based system to integrate the ProPolice work into our tree over two years ago. I myself had this stack protection code integrated by the author of the code on my systems in 2000 which was integrated in the MicroBSD 0.1 release. Yes, We forked OpenBSD, Theo and the OpenBSD group have done a wonderful job,as have the rest of the
BSD groups and we have coat tailed a bit, but we are growing from a core team of 6 people to a larger group. We will continue to integrate the Best Features from all the BSDs and share the code as we have done in the past, like CGD from NetBSD,
and porting Jail from FreeBSD, along with Features not found in any other BSD but MicroBSD so far. We had FreeBSD/OpenBSD stack protected systems in
2001 and believe we were the first BSD to integrate the code.
OpenBSD the first... No, just a larger project with a larger user base and more exposure. We just wanted to try to contribute. I think the quietness of everyone is due to this not being "new", maybe new to OpenBSD, but not new over all. All the BSDs have a reason to be there, and hopefully through time we will become known as such also. This is just my rant/thoughts on the www.deadly.org post and the mailing list traffic.
Free means no restrictions, ironic the FSF's GPL forces restrictions, isn't it? What's your definition of free?
>All OpenBSD really needs is a nifty installer - and it could borrow one from Debian, soon.
Get a good installer by borrowing the Debian installer? You're kidding, right?
Wrong. There are several convergent efforts to build a simple, clean GUI installer for Debian along the lines of Mandrake's (have you tried Knoppix? That's Debian. And if they dither about it, I'll port Mandrake's installer myself!). The Debian system includes FreeBSD as one OS core (along with the GNU Hurd), so it would be close to trivial to include OpenBSD.
Got time? Spend some of it coding or testing