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."

Comments

linux should have non-exec stack by defualt

[stonebeat.org]

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.

Re:linux should have non-exec stack by defualt

[use_compress]

Didn't many of the old FORTRAN programs execute data directly off the stack? I know that most of this has been phased but this move could lead to many unstable programs that are supposed to be handling aspects of the server's security.

Re:linux should have non-exec stack by defualt

[norculf]

Yeah, lots of popular applications are written in FORTRAN...

Re:linux should have non-exec stack by defualt

[fifirebel]

There are several reasons why Linux does not have non-executable stacks yet...

One of them is that gcc and the kernel use trampolines. From the gcc docs:

A "trampoline" is a small piece of code that is created at run time when the address of a nested function is taken. It normally resides on the stack, in the stack frame of the containing function.

AFAIK, linux uses trampolines at least in these places:

• Gcc uses them for nested functions (not very common though, but glibc has quite a few of those).
• The linux kernel uses (used?) trampolines for signal delivery.

Both problems can be addressed (the openwall patches take care of the kernel trampolines), but it's not as easy as turning off the PROT_EXEC bits in the stack.

Also, a non-exec stack is not a silver bullet: it only makes exploiting buffer overflows somewhat harder. Check out this article from Solar Designer (the OpenWall patch author).

On top of the above:

• Multithreaded programs have more than one stack, and they're not necessarily contiguous.
• As Theo's mail says, the i386 arch (which is still the most common linux arch, despite its suckiness) has a very limited way of implementing PROT_READ && ! PROT_EXEC pages:

  The i386 is not capable of doing per-page execute permission. At most it is only capable of drawing a line through the address space, by limiting the code segment length (using the code segment register). So we can say, "from 0 to this point is executable" and "from that point on to the end of userland is not executable".

You may now understand why Linus has so far judged that a non-executable stack was more trouble than it was worth.

Re:linux should have non-exec stack by defualt

[The-Perl-CD-Bookshel]

Little known fact, the first Doom was written in C# and uses the .NET framework

Re:linux should have non-exec stack by defualt

[andrewski]

Easy! Just change your viewing prefs to not show signatures. That way you won't have to bitch to the world about it EVER again!

Re:linux should have non-exec stack by defualt

[Clover_Kicker]

>Easy! Just change your viewing prefs to not show signatures. That way
>you won't have to bitch to the world about it EVER again!

I suppose that's one approach. I just PLONKed the guy.

Re:linux should have non-exec stack by defualt

[kasperd]

I'd have modded that comment Insightful. But it already had Score:5, Informative.

Re:linux should have non-exec stack by defualt

[Anonymous Coward]

This is plain stupid. The kernel stack has nothing in common with user stack, so trampolines are a special issue there.

Then, trampolines are not the only way to implement nested functions. Just a neat one.

And finally, gcc has all the hooks to turn the memory protection back on for the little chunk that wants stack execution.

Guess what ? gnu-ada uses trampolines, and it works on OpenBSD current...

Re:linux should have non-exec stack by defualt

[giel]

HUH!?

Sorry. I don't get it. A short and rough interpretation of the 80386 Programmer's Reference Manual, (c) 1986 by Intel.

Memory access to segments is secured using descriptors. The i386 distinguishes code and data segments (by segments I mean a segment with a certain descriptor). A stack segment is a data segment.

CODE - A code segment can be executed (loaded into CS). A code segment can be set to non 'readable' (to prevent it form being loadable into DS,ES,FS or GS). A code descriptor does not allow write access to a code segment.
DATA - A data segment is readable and can be set to read/write access. A data descriptor does not allow execution (it cannot be loaded into CS).

These definitions themselves leave very little room for insecure memory management. But: one or more descriptors can be used to describe the same piece of physical memory and so it is possible to define code segments which can be written to.

Privilege levels are available in 4 levels. You can secure memory to be accessed only for processes of privilege level 0..3, 1..3, 2 and 3 or 3 only. For example: 0=kernel, 1=shared libraries/drivers, 2='secured' program code, 3=program/thread code.

IMHO this gives loads of opportunities to secure memory access on a i386 box. I assume it has something to do with the flat memory model used combined with shared address space and problems matching the PROT_EXEC, PROT_READ, PROT_WRITE model to the i386 implementation. A short scetch:
Available
--x Code
r-x Code Readably for data descriptors
r-- Data Readonly
rw- Data Read/Write access
Not available (IMHO insecure or useless)
--- Useless, inaccessebility is done by privilege levels.
-w- Useless, does not make sense
-wx Insecure
rwx Insecure
Good enough techno babble on the i386 architecture.

IMHO a general possible solution to make buffer overflow based attacks harder, if not impossible, would be seperating the return address stack from the stack containing local data, usually these are on one and the same stack.

Re:linux should have non-exec stack by defualt

[defile]

Also, you don't need an executable heap/stack for these overflows to cause damage (overwrite access tokens, change flag states, etc.)

Sure every little bit helps, but it's still kind of a losing battle.

IMO, it would be better to spend more time educating people and making it socially unacceptable to use C/C++ when they could just as easily use a high level language with bounds checking. You know, like LISP people have been saying for 30 years.. ;)

But alas this is a touchy subject.

Re:linux should have non-exec stack by defualt

[p3d0]

What a process does with its own memory is its own business. Programs that allow stack-smashing attacks are broken and should be fixed, period.

Having said that, there are lots of buggy programs, and a lot of them run with elevated priviledges. I wonder if it would make sense to write-protect the stack, and then email a core file to the program's maintainer when an attempt is made to execute the stack. :-)

Re:linux should have non-exec stack by defualt

[p3d0]

Non-writable stacks don't solve the buffer overflow problem. Programs with buffer overflow exploits are buggy and should be fixed. A non-executable stack just detects the problem, which is fine if that's what you want, but it's no solution.

And your taxonomy of memory permissions is naive.

• Memory with no permissions is used in shared-memory clusters to make memory temporarily inaccessible so the memory sharing system can detect subsequent accesses and propagate the appropriate data. This must be done on a page-by-page basis. (Whether it'd done by priviledge levels or whatever is an implentation detail of mmap.)
• Writable-executable memory is essential for Java Just-In-Time (JIT) compilers. To achieve decent performance, jitted code must be self-modifying to deal with newly loaded classes.
• Even write-only memory may be useful for some kinds of interprocess communication.

Your idea of separating return values and data on the stack has some merit, but I reiterate: buffer overflow attacks are bugs that should be fixed. Systems to detect them and reduce damage are good, but they are not a solution.

Re:linux should have non-exec stack by defualt

[giel]

I'm the last one to deny that possible buffer exploits are bugs and simply must be solved.

• Memory ... Agreed, but the implementation will be very machine dependent, and the i386 simply offers a solution to prevent any access for certain privilage levels.
• Writable-executable ... The JIT issue: that seems strange to me. First of all I'd rather change memory permissions from rw- to --x after the code has been assembled by the JIT compiler than writing it directly into rwx memory. Second java has no way of directly accessing memory, other than perhaps atomic attributes inside classes. There is no way of casting a reference to a class into any integer kind of value and thus gaining the possibility to mess with it. AFAIK buffer exploits are hardly possible in java programs, but I can image things go wrong if you send a naive/buggy program something huge causing memory problems.
• Even ... Under very rare conditions. I know some systems map IO to memory and I can image it would be usefull in such a case. But for most deamons and user programs I don't think it's very usefull.

I still think that the lacking combinations of access rights should be easily circumvented, and therefore a useless and in the case of any ?wx simply are dangerous.

Re:linux should have non-exec stack by defualt

[deKernel]

IMO, it would be better to spend more time educating people and making it socially unacceptable to use C/C++ when they could just as easily use a high level language with bounds checking. You know, like LISP people have been saying for 30 years.. ;)

This will without a doubt, fix the problem because the yahoo's that are doing this crap are concerned about doing 'socially unacceptable' things.

Re:linux should have non-exec stack by defualt

[johnnyb]

Don't insult McDonald's Certified Food Specialists in that way.

Re:linux should have non-exec stack by defualt

[gr8_phk]

The guys doing the Hammer port have been talking to no end about this. Have a look over at www.x86-64.org mailing list archives. There's lots of talk about banning trampolines and such. It sounds like Linux on Hammer will not allow executable stack, but since I'm only an occasional lurker there I can't say for sure. Now if only I could buy one...

Re:linux should have non-exec stack by defualt

[p3d0]

I'm not sure I follow your comments regarding the JIT. I think you're thinking of a Java interpreter, not a JIT compiler. Once the code is compiled, it's no longer java. It accesses memory and slings data just like any other assembly code, so I'm not sure what your point is there.

Also, as I said in my previous post, the JIT issue is not a one-time compile-then-execute thing. I agree that such a scenario could probably just change permissions after compilation is finished. The issue I'm referring to is that jitted code must be self-modifying to be efficient. Let me explain one scenario...

Most virtual methods are actually monomorphic at runtime (meaning that they only have a single target method despite being virtual). Thus, a crucial optimization is called "devirtualization" where you optimistically assume that all methods will be monomorphic until you have evidence to the contrary. This allows you to make direct calls to those methods, rather than more expensive indirect calls. More importantly, you may be able to inline the target method and get huge benefits in later optimizations. However, if your optimism turns out to be wrong, the code must be able to heal itself to undo these falsified assumptions in order to continue to run correctly.

Your arrangement would require two otherwise unnecessary mmaps to allow this healing to occur, which would hurt performance.

I think an OS has no business trying to protect an application from itself; only from other applications. If the OS prevents an application from doing something "just in case" it might hurt itself, then some applications will suffer.

Having said that, I guess there's no harm in making stacks non-executable by default, and applications could make their stacks executable if they want. But if you're suggesting that readable-executable memory should be banned by the OS for security reasons, then I object to that for performance reasons.

Re:linux should have non-exec stack by defualt

[the_canadian_worm]

IMHO, it wouldn't be such a losing battle if the C standard library was cleaned up to remove some of the more prone functions. For instance, gets() is a classic example. There was no attempt to allow the caller to specify the maximum input length...

Re:linux should have non-exec stack by defualt

[lpq]

you mumbled:
> Sure every little bit helps, but it's still kind of a losing battle
===
Well, which is it? Does it help or is the battle lost? Should we just toss our passwords and encryption and throw away all car and house locks? Fighting a moving target isn't the same as a fighting a losing battle.

On the other hand, anyone that expects a "silver bullet" will find that it works for a while. Then the "foe" adapts. They adapt. You can either believe resistance is futile, or you can believe that resistance is not futile.

What you believe will ultimately define your reality and if you get suckered into believing what losers believe, you'll be a loser yourself. If you are fortunate enough to have positive minded friends that don't make excuses, you'll find yourself more successful.

Ultimately, you'll get what you believe you'll get. People who believe the worst are more likely to make it come true (since failure and tearing things (or people) down is easier than success and building things up).

You can say locks no front doors are 'no silver bullet' since the windows are so easily broken, and locks are expensive and a pain, and we like not having to carry keys...and I'm so forgetful I don't know how to find my keys all the time anyway...so locks on front doors are bad! Seems like same logic goes along with non-executable stacks.

Sorta like the power of a snowflake...but you put enough of them together and a avalanche has alot of power.

-l

Re:linux should have non-exec stack by defualt

[Ed Avis]

Steady on - C++ is a high level language, at least by the standards people always used to use, and it does have a good range of bounds-checked containers (safe arrays and the like). It does allow you to do low-level stuff if you need to and you know what you're doing; the trouble is that too many people who don't really need the low-level memory access still don't use safe containers for spurious performance reasons. Yes, moving everyone to Lisp or ML or Perl or even Java would solve a lot of memory scribbling problems, but so would making sure everyone uses safe string libraries rather than char*s and safe container libraries rather than raw arrays.

Also you can use tools like Splint and CCured to check at compile time and at run time for unsafe memory accesses. As with so much else in C and C++, you can write safe and correct memory access, and you can shoot yourself in the foot. You just have to take care and do the right thing, or if you don't want to worry about being careful then switch to a different language. But switching is not the only way to solve the problem.

Re:linux should have non-exec stack by defualt

[pstemari]

Old FORTRAN compilers didn't even use a stack. IBM mainframe compilers generated a static variable for each subroutine call, and swapped the value of R14 before making the call and restored it after return. That's why FORTRAN (and Cobol) didn't support recursion or truly local variables.

Re:linux should have non-exec stack by defualt

[pstemari]

All of that doesn't help you when the desire to use a flat memory space limits you to a single data segment and a single code segment, set to begin at the same location.

Re:linux should have non-exec stack by defualt

[giel]

Partially exactly my point ;-)

Re:linux should have non-exec stack by defualt

[Tony-A]

IIRC, standard calling conventions:

L 1,=A(parameter_list)
L 15,=A(subroutine)
BALR 14,15

14 -- return address
15 -- entry point of subroutine
13 -- save area
1 -- parameter list (list of addresses, last one had high bit set)
12 -- where PL/I (F level at least) keeps its state

STM 14,12,12(13) -- IIRC
Chain new save area (register 13) to old save area
new save area at the beginning of block of storage for this subroutine. ...
L 13,???(13) -- get old register 13 back
LM 14,12,12(13)
BR 14

You're right about recursion.
A calls B calls C calls D calls B
Going in works,
B returns to D works.
D returns to C works,
C returns to B works.
B returns to A does NOT work, goes back to now defunct D.

concrete galoshes

[Forgotten]

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.

Re:concrete galoshes

[coene]

OpenBSD does not secure by limiting or removing functinality. Instead, it secures through proper programming, working as a team, and tackling issues in sequence.

I understand your joking, but point the next one towards the right area :)

Re:concrete galoshes

[Forgotten]

In truth I agree (mod grandparent down!). But there is a fine line between removing functionality and failing to add it (or delaying addition indefinitely).

I have used OpenBSD for some task-specific servers, and undoubtedly will again. I'm very glad it exists (regardless of the personalities involved) because it defines one end of a spectrum, from slow-but-steady to willy-nilly. Actually defining that spectrum can be someone else's flamebait. ;)

Re:concrete galoshes

[corsec67]

Also known as no network access. Power might be an issue, but I don't know of a virusses spread by power line, but to be safe, you should use a generator, in a Lyden cage, but don't for get the aluminum foil cap, and underwear.

Re:concrete galoshes

[evilviper]

As an OpenBSD user (/sysadmin/porter/etc) I have to say it is not always the case. Such as Apache now being chrooted. Sure, it's easy to un-chroot it, but it just goes to show that sometimes security and functionality are mutually exclusive, and in those cases Theo goes for security, so long as it can be undone for those that want the features.

Re:concrete galoshes

[0x0d0a]

not secure by limiting or removing functionality

This argument is, at best, semantics -- the latest-and-greatest versions of software do not show up in OpenBSD.

A not insignificant degree of OBSD's security comes from the fact that it simply doesn't enable a ton of services out of box. RH used to run *tons* of daemons out of box in the 5.x and earlier days, so it was "less secure". By that metric, classic Mac OS (which *never* had a remote root exploit out-of-box) beats OBSD in terms of security. :-)

Re:concrete galoshes

[haroldhunt]

>OpenBSD does not secure by limiting or removing functinality.

Yeah, OpenBSD secures by removing vowels. :)

Harold

Re:BSD is dead

[stonebeat.org]

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.

smp blah.

[sithe]

Yah, now If only I could run Open BSD on a system with more than _one_ processor. =/

-sithEnder

Re:smp blah.

[MalleusEBHC]

You may get your SMP in OpenBSD soon. From what that article says, they are supposed to have a kernel up by now (although that was their estimate, so you can never be sure).

Re:smp blah.

[drsmithy]

You can _run_ it, you just only get one CPU. We use it on some multi-CPU firewalls (multi-CPU because we bought a dozen machines in a package and they _all_ came with two CPUs).

in case of slashdotting

[joe_bruin]

google cache, in case of server is slashdotted

Re:in case of slashdotting

[sirsampson]

hahaha, a google cache of a link to groups.google...

now is that funny, a troll, or a karma whore :)

Re:in case of slashdotting

[stonebeat.org]

that is interesting. a google cache of the google news. That's Deja Vu once again :)

Re:in case of slashdotting

[runderwo]

I think it's probably funny because it's such a blatant karma whore. :)

Most Secure OS

[OverlordQ]

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.

Re:Most Secure OS

[Ryan Amos]

I should hope OpenBSD is the most secure OS out there. That is the main goal of the project. It's definately not the fastest or most feature-rich OS out there. But, that's what they do, and if you need ironclad security, OpenBSD is the way to go.

Re:Most Secure OS

[modulo]

Theoretically, a capabilities-based OS like EROS would be even more secure than OpenBSD, if the implementation was as careful. Of course, the same tradeoffs that OpenBSD makes would be even more extreme (application support definitely, performance probably I would think)

Re:Most Secure OS

[Tony-A]

I should hope OpenBSD is the most secure OS out there. That is the main goal of the project.
Only one remote hole in the default install, in more than 7 years!
Uber secure? Yes. Secure? Probably not, but they're working on it.
Actually that one remote hole is a stronger statement for OpenBSD than when there were none known.

Re:Most Secure OS

[hopeless case]

Don't you get most of the benefit of EROS with linux+LIDS?

I am curious what capabilities advocates think of LIDS.

The LIDS patch is much less extreme of a measure than trying to implement a non executable stack when people have found interesting uses for an executable stack.

Re:Most Secure OS

[modulo]

From what I gather, what LIDS, and other "Trusted (insert OS here)" variants actually are doing are shoehorning some of the capability monitoring and authorization ideas into existing operating systems, while EROS claims to be a pure capabilities system that emulates a Unix environment for "legacy" applications.

The difference appears to be granularity and pervasiveness, rather than the nature of the approach.

(ObTopic) OpenBSD takes a different approach altogether, going on the theory that it's OK to have all of your eggs in one basket, if you really watch that basket.

One camp seems to say (oversimplifying here, of course there are great Unix designers and great implementers of other systems) that insecurity is the result of poor design, and the other camp blames poor implementation, but really the computer doesn't know the difference between the two - it's just bits and bytes. The distinction is pretty arbitrary.

Douglas Hofstadter makes a pretty good case that a side effect of Gödel's Incompleteness Theorem is, no matter how hard you try, you just can't make an unbreakable machine in this universe. Not that you shouldn't try to keep ahead of the riffraff :-)

Where you draw the line will depend on what environment you want. The Windows crowd will say that OpenBSD is extreme, and OpenBSD to the EROS folks probably looks overly conventional. To each his or her own.

Re:BSD is dead

[sirsampson]

X isn't insecure, really... oh wait, is that a window I hear breaking in the background... gotta go...

Re:Why not Windows

[bsharitt]

I don't see how an 85% profit margin makes the oepraing system less secure.

open source security

[calib0r]

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.

Re:open source security

[Anonymous Coward]

Cisco already seems to have put in measures to combat the spread of worms. Whenever someone starts putting a high load on the router, it crashes. Problem solved.

Interresting...(might be OT)

[Mathness]

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.

Re:Interresting...(might be OT)

[muixA]

Just download the install floppies (3 of them), and boot. It will be painless if your hardware is like mine.

I still run Linux on almost all the PC hardware I deal with, FreeBSD has a real nice feel about it, but just doesn't have everything I need.
--
Matt

Re:Interresting...(might be OT)

[shamilton]

You will want to start with FreeBSD. It is the most general purpose and Linux-like. The installer doesn't hold your hand, but it is easy to get used to. Statistically, you will never go back to Linux. From here you can then try OpenBSD and NetBSD. They are a lot slower and more limited, and are really meant for niche applications. For example, OpenBSD might be a better choice for a firewall.

Amusingly, at my workplace, we run more FreeBSD boxes than OpenBSD, and have never had a FreeBSD box taken. There has been at least one incident involving an OpenBSD box.

sh

Re:Interresting...(might be OT)

[nuintari]

I'm gonna have to disagree with you on several points here.

1. I have found Open is actually easier to install than Free. Granted, this could be due to my love of purely simple methods, which the Open installer is. net is, in my mind, the hardest of the three, with free being very much in the middle.

2. I fail to see how Open is slwoer and more limited. It is true that Free has the most amazing tcp stack in production today, but Open's is pretty tight, and is plenty efficient in disk I/O and CPU usage. Its also not limited in any way. The stock install has a lot less "stuff" in it than most other OS's, but I consider that a definate bonus. "Ports" in a few extras, and you have an awesome, httpd, ftp, mail, dns, whatever server. In my company, we have dual purpose dns/mx backup OpenBSD machines.

3. While it is true that OpenBSD makes a dandy firewall, and quite frankly, I would use nothing else but OpenBSD for said purpose, that's not all its good for, and this "typecasting" has to stop. Does just fine in any other role too, hell, I have an OpenBSD DESKTOP. DESKTOP!

4. As for an Open box getting owned, not surprising. The final step in a secure OS, is knowing how to maintain it, and miantaining Open is no picnic, once free is up and running it is far easier to lean to patch it. Both are fairly simple once ya get the hang of it, but the free learning curve is much faster. And quite frankly, a lot of businesses deploy tons of freebsd machines, lots of admins know it. Open is a newer project, with a smaller real world footprint.

Just my unspellchecked thoughts. Its almost my birthday, I no longer feel compelled to check my typos out.

Re:Interresting...(might be OT)

[shamilton]

1. I can't really comment, I've only watched it be installed. I would agree that NetBSD is the hardest, the installer doesn't really seem to flow. Personally I would prefer to just receive a shell when I put the CD in. I can fsck, disklabel, fstab, and untar all by msyelf, thank you very much.

2. OpenBSD and NetBSD are definitely a lot slower than FreeBSD. NetBSD feels a lot less responsive than FreeBSD. Both take much longer to boot. I believe the reason is simply that speed hacks are hard to port and are potentially insecure.

3. My original post was going to address OpenBSD desktops, but I decided not to. Using OpenBSD as a desktop is sort of like using a weed whacker to mow your lawn, then saying "Weed whackers do just fine in any other role!" Maybe so, but there are better solutions available.

4. This wasn't a maintainence thing. As I recall, it was the sshd thing. It got hit right away (as the sshd vulnerability was being announced) by a script which hit all our boxes. The irony is that the FreeBSD boxes were not vulnerable, because of patches to OpenSSH made by the FreeBSD developers. This is actually something of a recurring theme with FreeBSD: major application is vulnerable except for the one shipped with FreeBSD, due to local patches. Personally I trust the network security of FreeBSD better than I do OpenBSD, but I believe it would be easier for a user to break root on a FreeBSD box than an OpenBSD one.

I enjoyed your sig.

sh

Re:Interresting...(might be OT)

[cpeterso]

As for an Open box getting owned, not surprising. The final step in a secure OS, is knowing how to maintain it, and miantaining Open is no picnic,

Doesn't that defeat the the purpose? If OpenBSD is more difficult to maintain than FreeBSD, isn't that a security problem? If security is difficult to use, users will either not use it or misconfigure it. Then your security features are pointless..

Re:Interresting...(might be OT)

[Arandir]

I'm a FreeBSD user, and a huge FreeBSD fan. But if you want the most "general purpose" BSD, then look at NetBSD. (But try FreeBSD and OpenBSD as well).

Re:Interresting...(might be OT)

[Shanep]

Personally I trust the network security of FreeBSD better than I do OpenBSD, but I believe it would be easier for a user to break root on a FreeBSD box than an OpenBSD one.

What? Can you make sense of this?

I also use OpenBSD as a desktop. It runs X11 and I like WindowMaker.

Open and Net a LOT slower than Free? Post some numbers please, because as a Free and Open user since Open 2.5, I find this rather exagerated.

Are you one of these people that equate a few percent as being a lot?

This wasn't a maintainence thing.

One very out of the ordinary incident and you've given up on OpenBSD "network security"? Talk about reactionary!

Re:Interresting...(might be OT)

[Anonymous Coward]

FreeBSD's better for the desktop due to a much more comprehensive ports collection.

FreeBSD supports SMP, too - not much use for firewalls but handy in a lot of other roles.

FreeBSD is also a better choice for those new to the *BSD world as it's more popular - there's more help out there for it

No disrespect to OpenBSD - it's a fine OS - but so is FreeBSD. And, IMHO, for most roles, FreeBSD is a better choice. Each to their own and all that, though.

Re:Interresting...(might be OT)

[bpalmer]

As someone that uses both extensively I've got some nitpicks.

1) No problem there. I prefer FreeBSD install, but Open is good too.

2) Limits that come to mind right now are SMP, some of the advanced routing (VRRP)... I'm sure there's more I've bumped up against, but I'm only on my second cup of coffee.

3) OpenBSD simply doesn't have all the bells and whistles that Linux or FreeBSD has. A recent version of Wine for instance, or OpenOffice (although I've read it can be compiled on Linux and copied over). And frankly comparing OpenBSD X11 to a Linux dist X11 (FreeBSD is somewhere in between) you'd see OpenBSD looses that race.

4) Huh? How is "patch -p0 /path/to/patch" any harder on OpenBSD than FreeBSD? As someone that uses both daily, I use exactly the same commands and utilities (CVS, CVSUP, Mergemaster, make...) on both systems. Please explain why the bar to proper maintenance on OpenBSD is higher?

Re:Interresting...(might be OT)

[bpalmer]

Errr, of course that should be "patch -p0 /path/to/patch". See afformentioned coffee deficiency.

Re:Interresting...(might be OT)

[bpalmer]

Sigh, Slashdot keeps dropping the ''in the command line, but you get the drift.

Re:Interresting...(might be OT)

[grub]

3. My original post was going to address OpenBSD desktops, but I decided not to. Using OpenBSD as a desktop is sort of like using a weed whacker to mow your lawn, then saying "Weed whackers do just fine in any other role!

I'm typing this on an OpenBSD desktop at my workplace. I run the Linux Citrix client for access to a machine in another city whereas some of our Linux machines can't because of incompatibilities.
Truthfully, most of the "features" that OpenBSD lack when compared to Linux are not as big as the "features" Linux lacks when compared to Windows. In fact.. I can't think of one reason that I'd have to downgrade to Linux after all these years of being a happy FreeBSD and OpenBSD user.

Re:Interresting...(might be OT)

[nuintari]

1. That's actually all the openBSD installer really is, except it makes sure ya do it in one particular order. And it does no network setup for you, just a little.

2. Never noticed that, but I am a big Open nut, and I honestly don't even have a free box right now.

3. Well, your sort of right, Open on thre desk, is sort of a niche tool for cerytaoin tasks, like a weed whacker, its why I also have a Linux desktop, and my game box, err... I mean, WinXP, all on a KVM.

4. You probably had 3.1 boxes, which were the ultimate low point for OpenBSD in a way. But 3.2 fixes all of that, and I thinbk its better than ever, with my favorite part being privalage escalation. Makes sshd much stronger.

Thanks, I liked my sig too, and I am now 24.... another grey hair.

Re:Interresting...(might be OT)

[nuintari]

1. Its opinion really.

2. I'll give ya that one, when Open gets smp.... I'll have a lot fo fomer linux boxes switched over.

3. Well, I never said ti didn't, but it gets the job done for a techy was my real point. I also have a windows, and Linux box on the same KVM, use whatever for my particular mood really. I'll use Open a lot more once I can compile Galeon on it without pulling out my own wisdom teeth and consulting them for advice.

4. Well, I have only had the Free patch system explained to me, and I heard it was completely different than Open's, I could 180 dgrees off though, and I am probabkly am. The only difference would be, I imagine, that the freebsd documentation on it has a little more detail. I'll put money on that.

Re:Interresting...(might be OT)

[nuintari]

No, not at all, any OS is gonna get owned if you don't patch it. trust a strock Linux/Win2k/FreebSd install? NEVER!

A lot fo people go with what they know, making it a more secure choice for them, than going with uber secure OpenBSD, and being forced to run it unpatched cause you either don't know how to fix holes, or don't think it needs it.

Its not really so much more dofficult per se, as it is harder to learn, and a less common skill ammoung sysadmins.

Because for many, many years...

[leonbrooks]

...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.

Re:Because for many, many years...

[teslatug]

Then they expect a month of bugfixing to make up for over 100 months of bugmaking.

No they don't. That's what the next version is for. How do you expect them to make money if you have a relatively perfect (from the consumer viewpoint -- tons of features already + secure) OS.

OpenBSD is pretty successful for its stated goal -- security -- likewise Microsoft is even more successful for its own purpose. No use in comparing until you have an OS that truly does both (sorry OS X is not there). I would venture and say that Windows is closer to being secure than OpenBSD is to being useful to the general public.

Re:Because for many, many years...

[Rick the Red]

I would venture and say that Windows is closer to being secure than OpenBSD is to being useful to the general public.

That's why I use both: OpenBSD runs my firewall and server, Windows is on my desktop. If I ever get enough money to upgrade this PC (it's in desperate need of more disk space) and enough time to play with it, I'd like to have it dual-boot OpenBSD as well. I'm sure I could migrate off Windows (except for games), but it's just too damn easy to stay put, especially when I can sleep well knowing the OpenBSD firewall is doing the security job that Windows simply can't. So for now, when I want my unix fix I log onto the server.

Re:Because for many, many years...

[j-pimp]

IRL, a month of porting applications would simply mean an order of magnitude more security holes to fix.

The ports collection does not go under the same intense security audit as the rest of the code. Only the base code, this means kernel, basic userland, apache, perl, gcc, sendmail, X and not much else. This means that if they port gnumeric(and let me know I will IMMEDIATLY order myself a CD set if they do), it will not be security audited. If I could just get Gnumeric and a JDK/JRE with slightly better compliance than 1.1 I would be quite the happy spreadsheet crunching AWT/JDBC form making whore. I wish I had a spare box lying around somewhere to take the time to ./configure && make && make install the tarball and see if I could help make it happen. Tell you what, if someone can get a gnumeric port for OpenBSD I'll be able to use it as my laptop OS and I will port and maintain tn5250 so I can telnet into as/400's for my dayjob. And perhaps I'll help with an SQL/Java open source project that would be of some use to someone lacking in that skill area.

For the lamens among us...

[zaffir]

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...

Re:For the lamens among us...

[da_spoon]

I do not have any links, but stack smashing is when you pass a large parameter to a program. If the programmer did not check the size of the input and assumes that it is smaller than the actuall size of the parameter. This then overwrites the stack(variable stoarge) and can get into the return section of the program. If it is able to get into the return section, OS's with EXEC Stacks may execute code that was passed with the overflowing parameters

Re:For the lamens among us...

[djschaap]

Put simply, "Smashing the stack" is a method of overwriting variables within a program (which are located on "the stack") with malicious CPU instructions. When done properly, the vulnerable application will jump to those malicious instructions and do Bad Things(tm).

Preventing the CPU from executing code located on the stack will in many/most cases prevent these malicious instructions from ever running (because they're located on the stack).

For a detailed explanation, see Smashing the Stack For Fun and Profit by Aleph One.

Re:For the lamens among us...

[p0et]

just do your research.. ;)

or if you're lazy, check the classical:

smashing the stack for fun and profit
http://www.phrack-dont-give-a-shit-about-d mca.org/ show.php?p=49&a=14

Re:For the lamens among us...

[Jeremi]

Roughly: A program's stack is where it keeps its temporary information, a sort of "scratch pad" if you will. Stack smashing is when the program has a bug that causes it to "scribble outside the lines", such that it overwrites info in its scratch pad in an unexpected way.

A common bug in programs is that when they are receiving input (from the disk, from the keyboard, but most relevantly, from the Internet), they forget to make sure that they have enough room to "write down" the input they are receiving, and so they end up writing right past the end of their scratch area and over other stuff. Typically, this will cause the program to malfunction and/or crash soon afterwards.... BUT:

Years ago, crafty nasty little hax0rs realized they could use this type of bug to gain control of a computer remotely via the Internet. What they do is they find a computer running a program that has this sort of bug, and then send it input that is too big for the program's buffer, and contains a little program. The buggy program duly writes the input onto its stack, munging some of its other data -- and the hacker has formed the input "just so", so that the data it overwrites is the data governing what the computer will do next. So instead of just crashing, the program then executes the hacker's program. The program then usually "unlocks the front door" of the computer to the hacker, allowing the hacker to control the computer by remote.

Making the stack non-executable means the the computer doesn't allow itself to execute any code that is located in the stack. This means that the hacker can upload his evil program, but he can't trick the computer into running it.

Why this feature hasn't been standard in all OS's since the invention of the MMU, I cannot fathom.

Re:For the lamens among us...

[mbessey]

Well, most C compilers allocate temporary variables on the stack, which is the same place that they use to keep track of where the currently-executing function was called from, so they can return to the previous function.

If your program overflows the end of a temporary string or array (due to a bug in the error-checking, most likely), it can overwrite other things on the stack, including the return address of the current function call.

So, the attacker sends in an enormous string, which "just happens" to contain some executable code that does something nasty, followed by the address of that same code.

The new return address overwrites the one on the stack, so that when the function returns, it actually jumps into the previously-loaded data on the stack, which then does something nasty.

Making the stack non-executable causes the program to crash when you try to exploit it this way.

You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.

Some of the other changes mentioned in the paper try to make it harder to exploit overwriting data on the stack, too.

Hope this was helpful,

-Mark

Re:For the lamens among us...

[An Ominous Cow Erred]

Quick explanation -- (really you should google for this info but oh well)

The stack is a LIFO (Last in First out) data structure. OS's and programs use it to store all sorts of data, but one thing it's commonly used for is storing return addresses for subroutines and such.

By "stack smashing" what people mean is the typical goal of a buffer overflow attack. A program that doesn't do bounds checking on an array of data can be fed a huge amount of data that exceeds the length of the buffer that it has allocated to hold that memory. It then starts walking over other parts of memory and runs into the stack (which exists in memory just like everything else).

If you overwrite a return address in the stack with a pointer that points to some code that you've written to memory with the buffer overflow you just did, you can execute arbitrary code and thusly take control of a system (with whatever privileges the program you just attacked uses).

Since a lot of your overflowing data is going into the stack, it's a potential space for a lot of the code you might want to execute. Since the stack should only hold data and pointers, not code, it's safe to make it non-executeable with the MMU. This makes it harder to write a buffer overflow exploit, although it doesn't totally prevent it (since you can stick your malicious code in non-stack space as well).

(Feel free to flame/mod me down for any mistakes in this explanation. :-) )

Re:For the lamens among us...

[PetWolverine]

Okay, I'm new to this--just started learning about how this works last Saturday (the timing is for obvious reasons). So, someone correct me if I go wrong somewhere in this explanation.

As I understand it, when a program gets data from the system's I/O, be it a hard drive, other drive or, notably, a network interface, it first reads it to a buffer, then into main memory. Problem is, when reading from a network interface, the program doesn't know ahead of time how big the chunk of data will be--it'll be a packet of virtually any size. If a packet arrives that's bigger than what the program expects, problems arise.

Of course, if the programmer is alert, (s)he'll insert some code to check the size of the buffer and make sure it'll fit in the place in memory allotted for it. But if one forgets this step, as soon as an extra-large packet comes through and is retrieved by this flawed bit of code, the data being retrieved from the network will overwrite something else already in memory, and the program won't know it's there, or what it is.

The next step is to get the program to execute this code. At the end of each function (you have some programming background, right?) are a few bytes telling the function where it came from, and where to jump back to when it's done. If the worm knows where in memory it's putting the code it wants executed, and if it has bytes storing that memory address in exactly the right place, the function will finish executing, check to see where it should go to next, and find a memory address that in fact contains a worm. The program jumps to the location of the extra data and executes it.

So the worm contains, in this order: 1) Lots of junk code to fill the buffer, 2) a memory address pointing to #3, and 3) executable code that does whatever the author of the worm wants.

A non-executable stack means that no matter what the hacker does, the data in the stack will not be executed. If a hacker manages to issue a jump command to a memory location in the stack, the kernel will object and the process will return an error.

The reason why page-by-page protection is necessary is because there is another memory location where a program can write whatever it wants (or whatever a worm tells it to), called the heap. Protecting only the stack still leaves a way, albeit a more difficult one, for a worm to infect the system, by putting some code in the heap and telling the program to execute it. The page-by-page protection the article talks about as the team's goal would allow the OS to keep any page of memory either writeable or executable, but never both. This means that any place a worm can write to through a buffer overflow, it can't later have the program execute, no matter what.

Re:For the lamens among us...

[CoolVibe]

An non-executable stack is just another hurdle. That just leaves exploits using the GOT (Globale Offset Table) or the return into libc exploits, which don't need an executable stack to work. And there are probably other trampolines on which arbitrary code can be run if an application is insecurely coded. It might deterr the script kiddie, but it won't stop the determinate blackhat.

Re:For the lamens among us...

[SuperFrink]

Aleph did a good job on this one. It's a classic. Exploit posts to bugtraq somtimes contain comments in the source code crediting this article.

http://www.shmoo.com/phrack/Phrack49/p49-14

Re:For the lamens among us...

[Scott Wood]

You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.

Not really. You can still control the program flow by overwriting the return address, and given the stack-only parameter passing scheme on x86, you can also supply arguments to whatever function you choose to return to (with register arguments, you'd be limited to whatever registers are going to be loaded off the stack before you return, and argument registers are typically not preserved by the callee). While the typical exploit that just wants /bin/sh to run would likely just call system() or execve() or something, if one really wants to run code from the stack, the stack could be set up to return to memcpy() with the arguments pointing at the code to be moved to an executable area, and a subsequent return value that points to the destination. Null bytes would present a problem with (at least) the length argument, assuming the overflow is from a C-style string, but a sufficiently clever attacker could utilize other library functions to patch in the needed null bytes.

Thus, it may make certain attacks marginally harder, but it doesn't stop foreign code from being executable. It's most visible effect would be the problems it causes to legitimate programs that may want to execute dynamically generated code on the stack.

While there is no silver bullet to these sorts of attacks, making the stack grow upward (or strings grow downward) would eliminate a lot more holes than a non-exec stack. Unfortunately, people are too bound by tradition, and still introduce new ABIs that use downward-growing stacks, even when there's no hardware bias against upward-growing stacks, such as on most RISC chips.

Re:For the lamens among us...

[Nevyn]

The main reference is... http://www.cs.ucsb.edu/~jzhou/security/overflow.ht ml

Re:For the lamens among us...

[Weirsbaski]

Making the stack non-executable means the the computer doesn't allow itself to execute any code that is located in the stack. This means that the hacker can upload his evil program, but he can't trick the computer into running it.

Why this feature hasn't been standard in all OS's since the invention of the MMU, I cannot fathom.

For x86 at least, it's probably because x86 doesn't have a feature to make some pages executable, and some not. (Operon a.k.a. Sledgehammer will have this as a new feature, though).

Re:For the lamens among us...

[jldrew]

The hacker's exploit isn't located on the stack - it just used the stack overflow to gain write access to the code segment, so making the stack non-executable hasn't actually affected what the program will do with the new code right ?

The hacker's code is on the stack. The whole point of a buffer overrun exploit is not, as you state, to write past the end of the stack. In fact, it's just to write past the end of the area of the stack allocated to some function.

For a long time, the whole buffer overflow idea seemed foreign, but after searching google and everything2, I realized that there's nothing magical happening,... the buffer overflow uses simple ideas I (you too probably) learned in early CS classes.

Here's my description of how the exploit works (as I understand it):

When you make a function call, space is allocated on the stack (memory available for programs to use) for: 1) the function's arguments, 2) the function's return address (where to go when the function is done), 3) the variables declared within the function. The idea is to use up the space for the variables within the function, and then use up enough extra space to overwrite the return address. Then, you can make the return address point wherever you want.

With that in mind, you fill the function's variable space with some code you'd like to execute. Then, you overwrite the return address to point to that code. Voila!

For example...

void myExploitableFunction()
{
<ECODE>
// This is my buffer, it's just a char array.
char buffer[16];

// Fill the buffer (and then some!)
scanf("%s", buffer);

return;

}
Of course, this example is only a simple example... but anyway... The malicious user would just supply scanf with more than 16 characters, and the buffer would overflow... yada yada yada

What I use BSD for

[harikiri]

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).

Re:What I use BSD for

[gonk]

Clearly, you're not installing Linux right. It is trivial to install a Debian system that is as basic as you want it to be.

Please try and learn the basics of something before you toss it aside as defective.

robert

Re:What I use BSD for

[khuber]

I thought FreeBSD was extremely primitive to use compared to Linux. It was like being stuck in a 1980s time warp. It's too server-oriented for what I'm looking for at home and a lot of the BSDness just seems quirky as hell to me.

-Kevin

Re:What I use BSD for

[harikiri]

Note the use of "I prefer" and "For me". I'm not saying that everyone should use BSD, only why for me its preferable on server systems.

And I have used Debian before (try installing it on an ibook!), but my preference in this area is still with Free/OpenBSD. =)

Re:What I use BSD for

[calle69]

i know alot of people using debian on ibooks either your lieing or you dont know how linux work. im not trying to be rude but your comment its really nasty

Re:What I use BSD for

[andrewski]

Actually, most Linux distros are cluttered and sluggish compared to FreeBSD. The Linux kernel tends to undergo frequent experimental revision, whereas FreeBSD stays basic and functional.

After some FreeBSD goodness, with the ports system, Linux feels bloated and primitave.

Re:What I use BSD for

[m0rningstar]

I use Debian when I'm on a workstation, or some servers. Primarily for when I'm feeling lazy, want packages (LAMP boxen spring to mind) and similar. It has many of the simplicities that I adore about OpenBSD.

But for a mail server, or a firewall box, or a primary UNIX file/print server? OpenBSD all the way (for me, at least). pf has an almost intuitive interface (though it processes the list backwards to someone who's a router/PIX jock). The box is inherently secure. And if I'm not using a lot of newer packages (forgive me. I'm no coder. I don't port stuff) it's rock solid.

And, I guess, some of the quirkiness is more natural to me than some of the Linux stuff.

So. I guess it's a matter of best fit, and not having a hammer and assuming everything is a nail. Again, for me, at least.

Re:What I use BSD for

[roybadami]

I thought FreeBSD was extremely primitive to use compared to Linux. It was like being stuck in a 1980s time warp. It's too server-oriented for what I'm looking for at home and a lot of the BSDness just seems quirky as hell to me.

Not to disagree with the above comment, but just to comment on it...

A few years ago people could have (validly) made the same criticism about the Linux distros' suitability for desktop (vs server) use.

Give it time; Linux (for better or worse) has more mindshare than the BSDs, and it's reasonable for the BSDs to concentrate on applications where their currently popular, and where they excel, rather than trying to do everything at once. This is exactly the situation Linux was in a few years ago.

And despite the fact that Linux has more mindshare than the BSDs, most people who are familiar with both prefer their favourite BSD to Linux for server applications. (cf despite the fact that Windows has more mindshare than Linux, most people familiar with both prefer their favourite Linux distro to Windows for servers.)

Even now, the Linux distros are largely playing catchup with Microsoft as far as the desktop experience goes (and the BSDs are playing catchup with Linux).

Part of the art of systems administration is choosing the best tool for the job. My home system currently consists of a Windows 2000 desktop, and a couple of machines (a server and a firewall) running Debian GNU/Linux machines; and yet I'm a BSD advocate!

Re:What I use BSD for

[Kashif Shaikh]

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.

I found this true with redhat and suse, BUT you can use another meta distro: Gentoo.

You only merge(Gentoo-speak for fetch/compile/install packages) on what u need and satisfies your dependencies. Bootstrapping a gentoo system takes a couple of phases, however after the 3rd phase you have a base system close to 400mb(extra megabytes are due to having a development system needed to compile everything).

Plus, you can customize specific packages such as compiling in gtk/kde support, etc with USE variables. And if that don't work, you can edit the ebuild script file right then and there and customize you're own version right there(i.e. adding --msdfs configure flag to samba to compile in Microsoft DFS support)

I won't bore you with more details, but you can check out www.gentoo.org.

Re:What I use BSD for

[tamnir]

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.

You should give Linux From Scratch a try. You will build your own Linux system, installing each component manually. No clutter, just what you need, and compiled the way you want it. It is a very good learning experience too.

Re:What I use BSD for

[epine]

In our small shop, we use OpenBSD for firewalls, FreeBSD for file servers, Debian and Windows 2000 for workstations. For any given purpose, any of these systems might have a decisive advantage. I listed them in my rough order of bias. At the top of the list is maximal purity coupled with the narrowest applicability. At the bottom of the list is maximimal impurity coupled with universal applicability. We try to push our subsystems uphill where possible, but we're not zealots about it.

If I had to pick just one I would pick Debian and I'd be 20% miserable all of the time, but hardly ever 100% miserable (because something you really depend upon works badly or isn't available at all).

My only complaint about the package system in Free/Open is that selecting your packages is somewhat more manual than it ought to be. It's a bit of a pain to clone a known configuration at a different revision level because you have to pick exactly the right package names. I'm no fan of dselect, but dpkg is pretty livable.

Either way, if the package system is your main area of concern, it's a certain sign you have nothing important to accomplish. They both get the job done well enough if getting the job done is your main concern.

Re:What I use BSD for

[khuber]

Oh yeah, and the ports system is overrated. I don't want to compile all that stuff. It's kind of a Rube Goldberg thing; just too much going on there. I don't know how a user who wasn't knowledgable about building software could deal with it. BSD init is an anachronism. FreeBSD clings too much to traditional Unix.

I agree that FreeBSD is technically very solid/stable and Linux is too experimental. It's not just the Linux kernel that's experimental either -- building the libraries to support a new version of something can be hell. Some Linux distributions have helped with this. With FreeBSD there is only one distribution, take it or leave it.

-Kevin

Re:What I use BSD for

[khuber]

Yes, ideally you would use the packages instead of the port system unless you have to set compile time options. I just thought emphasizing ports except for extremely technical users was a bad idea, but that is always one of the things touted by FreeBSDers.

-Kevin

Re:What I use BSD for

[axxackall]

You can install Gentoo from the source code, but if you need just a shot to introduce Gentoo - try GRP, reference platform. The only difference is: no bootstraping (it means that someone has already compiled everything for you).

Re:What I use BSD for

[afabbro]

I agree with this sentiment, but...why does OpenBSD still ship with sendmail, uucp, etc.? I often don't need them. You can turn them off, sure, but why not instead make them admin-addable instead installed-by-default? I've never had this answered to my satisfaction by the OpenBSD crowd ;)

Re:What I use BSD for

[nitehorse]

Just had to comment on this line:

FreeBSD clings too much to traditional Unix.

Heh.

And what did you expect it to cling to? Traditional VMS? Don't forget that FreeBSD IS UNIX. FreeBSD is a direct descendent of the code from the original 4.4BSD. THIS IS UNIX. Love it or leave it.

(Personally, I love FreeBSD and 5.0 kicks major ass. Linux is cool, but I use Gentoo, which is arguably more BSD-like than any of the other distros except for maybe Slackware.)

Re:What I use BSD for

[Kashif Shaikh]

Did you read the fucking parent post I replied too? You seem jealous, anyways...

He stated that Linux distros are 'bloated' and said he prefers BSD. I replied and told him about Gentoo.

In no way did I say "BSD is dead", but rather just described some flexible parts of Gentoo. Sure its inherits BSD ports ideas, but there is nothing wrong with other free OSs implementing good ideas.

Yes, the documentation is fresh and light, and some areas need more work -- you can't blame gentoo as they started recently while others have been on the map BSD/linux map for 5 years or so.

Re:What I use BSD for

[tigga]

I agree with this sentiment, but...why does OpenBSD still ship with sendmail, uucp, etc.?

Regarding sendmail - you have to send some error messages, daily reports etc. It's essential part of system. You may use other MTAs but why bother?

I know UUCP was phased out from FreeBSD 5.0. I think OpenBSD will follow.

Re:What I use BSD for

[khuber]

And what did you expect it to cling to? Traditional VMS? Don't forget that FreeBSD IS UNIX. FreeBSD is a direct descendent of the code from the original 4.4BSD. THIS IS UNIX. Love it or leave it.

That's exactly the problem, clinging, the "THIS IS UNIX" attitude. I think most of it is nostalgia.

Traditional Unix is an anachronism. It's stale. Most commercial vendors left BSD behind in the 80s for System V, POSIX, ... HP/UX, AIX, IRIX, Xenix/SCO and Solaris are all svr4 based. Ken Thomson and Dennis Ritchie both moved on from BSD to Plan 9. Bill Joy works for Sun.

Personally I'm looking forward to more interesting stuff like GNU Hurd. There's a whole world of OS development out there and it's not monolithic 1980s BSD.

-Kevin

Re:What I use BSD for

[khuber]

Also, your history is right for general purposes, but FreeBSD is not exactly a direct descendent of 4.4BSD. It was originally based on 4.3BSD Lite aka Net/2, then later 4.4 Lite (because of legal problems with 4.3 Lite), which was stripped of USL (by then owned by Novell instead of AT&T) code that couldn't be distributed for legal reasons. Again, most (all?) vendors have gone to SVR4-derived OSes which of course did merge several of the BSD extensions into System V. But my point is still that they moved on.

-Kevin

Re:What I use BSD for

[Leto2]

Just for the record, installing Debian with just the bare minimum will result in a very very small base system, no cruft. Not even less...

Re:What I use BSD for

[spinkham]

Source Mage is another source based distro I'm involved in, and we solve the tracking problem by using installwatch. Works quite well...

Re:What I use BSD for

[faeryman]

Well, while you wait for Hurd to support a hard drive bigger than 1gig, I'll be watching my host's FreeBSD server support 300 web domains very well.

And while I respect the works of Dennis, Plan 9 is a poor excuse as a replacement for FreeBSD right now. I must ask though - have you ever looked into at all? It takes the traditional UNIX idea of "Everything is a file" to the next level. If you think its the next step, then why is "traditional" Unix stale when its ideas are still being used?

Deeply cool.

[JimmytheGeek]

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!

it will be impossible to JIT code on OpenBSD

[Anonymous Coward]

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?

Re:it will be impossible to JIT code on OpenBSD

[dpletche]

Right, that would be a terrible problem for a Java virtual machine running OpenBSD, if one can imagine such a thing. I'm sure the OpenBSD team will get to work on that once:
* Microsoft releases source for all products under GPL; fixes all bugs and security holes
* Linux developers get bored, call it quits
* Intel admits Itanium is a flop; brings back Alpha

You do understand that stack protection pertains to execution of native processor instructions, right?

Re:it will be impossible to JIT code on OpenBSD

[dpletche]

Doh, I misread that, never mind...

Thank goodness - it's about damnned time!

[mbessey]

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

Re:Why not Windows

[PetWolverine]

Because they're making their OS for profit, and they find they can sell a shitty OS. It costs extra to make it not be shitty, and it's not worth it to them.

Notice that it's apparently worth it to Apple--hence the move to a Unix base. This is OpenBSD; Darwin is based on FreeBSD, right? But maybe somebody will find a way to incorporate these changes into Darwin, or maybe Apple will do it themselves. I would certainly appreciate it if they did.

But What About...?

[ewhac]

Theo de Raadt writes:

W^X is a short form for "PROT_WRITE XOR PROT_EXEC". The basic idea here is that most buffer overflow "eggs" rely on a particular feature: That there is memory which they can write to, and then jump to.

What if there was no such memory? Does a normal Unix process have memory that is both writeable and executable? Turns out they do: [ ... ]

But do they need it? [ ... ]

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

Re:But What About...?

[PetWolverine]

What I want to know is: If a program can change the permissions of a page after creating that page, what's to stop a worm from finding a way of exploiting this?

Example: A hacker sends a packet that exploits a buffer overflow bug to insert some malicious code into memory. The computer won't execute it because it's writeable, and it doesn't execute writeable pages. But that's okay! The worm cleverly inserted the data into a location it knew was writeable, but would eventually become readable. Sure enough, later on another function makes that location executable and then executes it.

So, this makes it far more difficult to get the malicious code to execute, since the creator of the worm has to know of a place in the program's memory that the program will later want to execute, but that's writeable right now, and furthermore has to depend on the program not to change that data in between when the worm overwrites it and when it'll be executed. But I have faith that a hacker somewhere will find a way to do this if people actually make it common practice to change a page from writeable to executable in the middle of a program...they are a creative (destructive?) bunch.

Re:But What About...?

[epine]

There are too many presumptions in this comment about JIT. The protections Theo is using are imposed by the VM system, which means the protections are relative to a *view* of memory. It's not obvious to me that the JIT compiler needs to share the same view of memory as the process for which it compiles. I can't bring myself to believe that for a typical invocation of the JIT compiler, one process transition is a dominant cost.

Re:But What About...?

[IcePic]

Example: A hacker sends a packet that exploits a buffer overflow bug to insert some malicious code into memory. The computer won't execute it because it's writeable, and it doesn't execute writeable pages. But that's okay! The worm cleverly inserted the data into a location it knew was writeable, but would eventually become readable. Sure enough, later on another function makes that location executable and then executes it.

The thing is that stuff written to memory by usual
apps are written into PROT_WRITE areas. These in
turn usually never gets mprotect()ed to another
status by the apps. A common exploit would normally
send malicious data to the app making the app copy
that data into an area that had both PROT_WRITE
and PROT_EXEC. Then, it would make the app jump into
this area.
So, you can always use bugs to have the code jump
from one place to another, but if the app doesn't
have any mprotect() code (mine never does =) then
it would be pretty hard for the exploiter to rewrite
the rules of his particurlar page using code that isn't
his own at all to make it possible for him to jump
into his own code.
Until you have found a way to execute your own code,
finding a call to mprotect() with *EXACTLY* the correct
args to make page 0x056df800 go from PROT_WRITE to
PROT_EXEC will be hard++.
So you end up with a chicken-egg-problem. The
malicious code could of course make its own page
PROT_EXEC. if it could execute mprotect(), and since it can't
execute anything without PROT_EXEC, it cannot run mprotect() at all.

Re:But What About...?

[p3d0]

It's not obvious to me that the JIT compiler needs to share the same view of memory as the process for which it compiles.

Are you assuming that a JIT and the executing program are in two separate processes? I'm not sure that's very practical. I suppose it's possible, but I don't know of a JIT compiler that works this way.

Anyway, jitted code must be self-modifying to deal efficiently with newly-loaded classes. You can't do that without writeable and executable pages. (Two trips to the kernel every time you want to insert a jump around a devirtualized call site would be death.)

What about other BSDs?

[PetWolverine]

Anyone know how portable these modifications are to other BSDs, notably Darwin?

Re:What about other BSDs?

[CoolVibe]

I don't think PPC darwin users need to fear. Shellcode on ppc archs gets so fscking large it's not useable for most stuff anyway. Not that programmers should code less secure on Darwin though. The arch being difficult to exploit doesn't mean that you have a license to produce sloppy code.

Re:Why not Windows

[the_mad_poster]

It's the difference between love of money and love of your job I suppose. People who are more interested in creating a product that THEY want (BSD developers) are more likely to create a product other people will want. People who are creating a product OTHER people want (as in MS developers making products for their managers' current whims) just won't have the heart for it. Of course... an outright disgust and ditrust of your customers helps create a faulty product as well :\

Re:Why not Windows

[ralphus]

Simple, I think. Because BSD works in security at the kernel level. Look at the levels of paranoia evident in their design... MS had long ignored this, and counted on application security, now they've just started to pay attention, but it comes as terrible palladium.

Oh joy... over bufferflow

[Woodrose]

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...".

Re:Oh joy... over bufferflow

[maxentius]

I agree, I'm getting tired of the two hours a day on the FX channel.

Oh, wait. You said "buffer."

Re:Oh joy... over bufferflow

[evilviper]

Hmm, sounds like an NT server...

"I'm in my happy place, I'm in my happy place... KABOOM! Muwahahahahaha!"

Re:Oh joy... over bufferflow

[Tribbles]

Under RISC OS 3.5, we get something similar:

oflaoflaoflaoflaoflaoflaofla

(except with accented characters).

I call it the "ofla" crash...

not the real theo, please mod down.

[joe_bruin]

Theo de Raadt spells his name like i just did, not "DeRaadt" (see article from story). besides, this is blatant troll. mod down.

Re:Why not Windows

[Penguinoflight]

Oh, they certainly can, even though a closed source model is much harder to be secure, given the smaller test, and development base. The problem is, it's simply not a high ENOUGH priority at most businesses. And why should it be, when people buy for marketing schemes, pretty graphics, and "but I just want my $10 modem to work" stuff.

Security isn't just a unix/windows war though, Solaris has had big trouble with security in the past, and so has IRIX. I haven't heard much about AIX, or HP-UX, but likely those machines wont be used for external servers anyway, so it's not QUITE as big a issue.

Quicky how-to (the real one is decent)

[JimmytheGeek]

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...

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 /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)

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.

Re:Quicky how-to (the real one is decent)

[Mathness]

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.

That will be most helpful, thank you :)

mathness at z42 dot dk

Nonexecutable stacks

[Sayjack]

A nonexecutable stack is no guarantee of safety. Solaris 2.6 demonstrated this here.

Re:Nonexecutable stacks

[Anonymous Coward]

A nonexecutable stack is no guarantee of safety.

Nobody said it was. To quote TdR, "We feel that these 4 technologies together will be a a royal pain in the ass for the typical buffer overflow attacker."

If you think "royal pain in the ass" constitutes proof, go back to math 101.

Re:Now th

[JimmytheGeek]

We use p200's with 64 mb ram for dns and web, no problems. We don't get a lot of traffic, true. But we're using something like .5% proc.

Really hard workers

[Amsterdam Vallon]

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"

Re:Can DoS ever be totally prevented?

[Ziviyr]

80 times a minute for over half a day is a little excessive.

If it was anything under 61 times a minute I'd be more sympathetic.

12 times a minute would be peachy. :-)

Re:We are much more secure

[Ryan Amos]

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

[ArchieBunker]

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.

Re:VMS

[Bastian]

Plus most script kiddies would be left scratching their head trying to use it.

All my servers run CP/M for the same reason.

Re:VMS

[Usquebaugh]

Security thru obscurity :-)

Let's here for the IBM AS/400.

Re:VMS

[burns210]

security through obscurity?

Re:VMS

[NoMercy]

*shudders* -- end of comment

Re:VMS

[chthon]

Security through obsolescence...

Re:VMS

[Viol8]

I'd be interested to see you run an entire financial data center using CP/M. I know you were being sarcastic but don't knock an OS just because its not "kool". It works and it works bloody well.

Re:VMS

[jhines]

Yes, but it defaults to a much looser config.

As a former VMS admin, you don't enable things you don't need. We didn't have the horsepower of today.

Re:VMS

[Foresto]

"VMS is probably a close second in terms of security. Its C-2 secure right out of the box."

Perhaps, but last time I checked, several Microsoft products had passed C2 as well. How secure do you think that makes them? Do you actually know what C2 certification means?

Re:VMS

[drinkypoo]

Last time I checked, NT had to be disconnected from the network to be considered C2 secure.

Re:VMS

[Sivar]

VMS is actually more secure than OpenBSD if you stick with VMS. Most of its extremely, extremely rare serious exploits are related to its POSIX compatibility (which added "Open" to OpenVMS). Even in the rare event that an exploit is found, 99.999% of hackers and crackers will have no idea what they are doing on a VMS system, and if they do, they have any number of TCP/IP stacks to deal with (because they are commercial 3rd-party addons, not part of the OS), and most won't bother playing with VMS security since public servers based on it are as rare as diamond hen's teeth.
If you'd like to try your hand at it, take a look at sisko.sbcc.cc.ca.us.

That said, the problem with VMS is that it sucks for nearly everything OpenBSD and Linux are useful for. Software for VMS is rare, and open-source software is practically nonexistant. VMS admins are rare and expensive, VMS is rare and expensive, the two whole architectures on which it runs (three shortly--Itanium added to Alpha and VAX) are rare and expensive. Try setting up a mail server and file server on VMS. Good luck.
Additionally, the documentation for VMS is very thorough, as in, "oh my god, nevermind" when you see the fleets of bookshelves which store dry, nondescriptive binders which each cover an aspect of the inter-related components of the system. VMS is as different from Unix as Unix is from Windows. It isn't really worth mentioning alongside OpenBSD because the two are completely, utterly different.

Not at the same time, anyway...

[mbessey]

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

Re:Why not Windows

[MoThugz]

It's has got more to do with priorities rather than budget. Windows was meant to be more of a "user-friendly consumer OS"... Although the security of Windows is at you say not as good as openbsd, I doubt that patching openbsd is at easy as opening the default browser, clicking on the Tools toolbar and click Windows Update.

Not trolling here, just showing another perspective to the issue.

Either way is good

[mao che minh]

Just responding to the inevitable Linux vs BSD threads: it could go either way. Both operating systems have their strengths and weakeesses. It just so happens that right now Linux has the major commercial backing.

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.

Re:Either way is good

[mao che minh]

That myth needs dispelling. What can Linux not do that makes it a bad choice as a desktop OS? The only "hurdle" left is vast commercial support for new games. And that isn't even a factor for the workplace.

1. Linux is better for developers (even some Microsoft developers like to use it as their developing platform - see the whole Roblimo Linux Fest deal)
2. There is more and better software available for Linux then Windows or Macintosh
3. Everything that the casual user needs is available after a 20 minute install process
4. Linux can be more easily managed regardless of overall network configuration
5. Again, and this can't be stressed enough since it is the main factor for management and pointy-hairs everywhere: Linux is far, far cheaper.

If an expensive cost, inflexibility, high risk factor, constant and forced upgrade cycles, and poor memory management makes a good desktop operating system then no, Linux sucks on the desktop.

Re:Can DoS ever be totally prevented?

[dfj225]

I don't ask for sympathy because I'm ok now...I've "learned my lesson". (The lesson I have learned is that next time don't get caught...j/k)

You can do JIT

[^BR]

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.

Re:You can do JIT

[ewhac]

You just have to explicitly mprotect(2) [openbsd.org] 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.

Ah, that's better. Theo's message didn't make that clear, and suggested that the kernel would globally disallow pages where both PROT_WRITE and PROT_EXEC were set, which would suck for several classes of application.

Schwab

Why not Linux?

[skink1100]

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?

Re:Why not Linux?

[JimmytheGeek]

I think they both have something to contribute. And let's face it, the personality types that seem to track with kernel hackers are generally stamped: "Does not play well with others" which forked BSD. On top of that, debugging might scale, but I suspect programming does not. There might not be enough scope in one project to contain the contributions of all the folks interested in free kernel stuff who can really do the work. Dunno.

There's a real difference in attitude, as shown in the different provisions of the licensing. BSD licensers are not concerned when someone takes their code and puts it in proprietary software, as MS did with tcp/ip code. GPL licensers do care that their work is not used by freeloaders/cherry pickers/parasites.

Why does anyone need this crap.

[BoomerSooner]

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]

You don't understand what is done

[^BR]

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.

Who are you?

[Theo de Raadt - OBSD]

OK, first of all, because you registered that username here, Slashdot wouldn't let me register "Theo de Raadt", so I had to settle for this.

Secondly, who the hell are you? Stop impersonating me on Slashdot.

Re:Who are you?

[Anonymous Coward]

oh look, another poser... fook off!

Re:Who are you?

[Anonymous Coward]

The "real" Theo de Raadt, with a uid of 646101? I find that a bit hard to believe.

Re:Who are you?

[allenw]

It just might be a giveaway--do the BSDs support uids that high yet on non-64-bit platforms? :)

[I know Linux has had that trouble in the past. I know it was supposed to have been fixed already, but I don't know for sure.]

Re:Neat

[La Temperanza]

Clueless : Informed

BSD fight buffer reign

[Chymaera]

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. :-)

Why not Windows

[bsharitt]

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?

Propolice

[Fzz]

The article quoted by the parent is seriously cool, if a little hard to read. Neither a non-executable stack or a non-executable heap will defend against this return into libc attack, nor will .rodata. I think propolice will though. Anyone know what the performance overhead of propolice is?

-Fzz

Re:We are much more secure

[whiteranger99x]

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

Well don't lose sleep over it, I pretty sure NetBSD tied up those loose ends LOOOOONG ago. :P

Ease of use/install.

[randito]

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.

The nice thing is .....

[Anonymous Coward]

Someone in FreeBSD and NetBSD with commit priviledges is surely looking at those patches.

Nice, but doesn't address the bigger problem.

[matman]

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?

Re:Nice, but doesn't address the bigger problem.

[Flower]

systrace anyone?

I'll leave that as a start.

Re:Nice, but doesn't address the bigger problem.

[dmiller]

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.

That is very much the approach that OpenBSD is taking - e.g. with privilege separated OpenSSH. If you exploit OpenSSH before authentication, you are unprivileged in a chroot that you can't write too. While this is not invulnerable (you may still abuse kernel bugs to escalate your privilege), it is a good deal better than before. OpenBSD also provides you tools with which you may further protect yourself: systrace - a system call policy checker.

Re:Nice, but doesn't address the bigger problem.

[ctr2sprt]

The problem is simple: the controls we have right now are far too coarse for the things we want to do with them. Running daemons as root is like putting out a match with a lake. They never need all the privileges of root. We need a way for root to drop its privileges selectively - or, better yet, a way to confer specific privileges to regular users. "The user apache can bind to port 80 without being root." "The user ftpd can chroot without being root." And so on.

It would also be lovely to see the tool which manages all this unify all the ACL-like aspects of the system into a single interface. Firewalls, filesystem ACLs, and privilege delegation are all remarkably similar, it'd be great to be able to define them selectively in groups (I think SELinux calls them "contexts") and confer them to various processes. Daemons can bind to ports, but not regular users? Easy: set the firewall ACL policy to deny, then grant the "daemon" context an exemption. Then tie in other useful privileges, like the ability to write to /var/run and send messages to syslogd. All these things are obviously related conceptually, but currently you'd need 3 tools to do it all (I don't think it's possible to regulate syslogd access this way, period, but I'm being optimistic and assuming it is).

Unfortunately, from what I saw of SELinux when I last used it, all this is some time off... especially the part where it's easy to administer and use. But to end on a positive note, there are a bunch of people who recognize this problem and are working hard to correct it.

Re:Nice, but doesn't address the bigger problem.

[matman]

ACLs are not the be all and end all of access control. Check out rsbac.org for examples.

Correction

[wfolta]

s/Lousy Security/Lousy Interface + Lousy Security/

twisted logic

[epine]

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.

Re:Why not Windows

[m8pple]

For Windows 2003 Server (what used to be .NET Server IIRC), they've recompiled everything with the /GS compiler switch, which hopefully will mean that at worst servers crash, rather than allowing overflows. The system talked about in the article sounds very similar, but I was a little unclear on whether this was in gcc, or whether they had explicitly instrumented all the kernel calls in some way.

For the 64 bit versions all pages have proper rwx permissions applied as specified in VirtualAlloc etc., but I'm not sure if the stack is no-exec by default.

Still, there are bound to be tons of protocol implementation errors that have nothing to do with fixed length buffers :P

Re:Why not Windows

[t0ny]

1. when you have a technical user base, they can work with the OS w/o breaking it. Then you dont need to make an idiot-proof product 2. when your OS is made as a platform for just about any application, there is a ton more code to work with (and add to, and fix, and improve, etc) 3. when you have 90% of the malicious programmers in the world trying to exploit your OS, there is probably always a problem to work on. So, its easy to complain and criticize someone. Show me a simple problem, and I will show you somebody who hasnt put a lot of thought into how to solve a problem. Because I have yet to encounter any 'simple' technical problems.

Terrific...

[NerveGas]

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

Re:Terrific...

[smash]

Its called using the correct tool for the job. You don't try hammering nails into stuff with a screwdriver do you?

Adding SMP will make the kernel more complex, and complexity is bad from a security standpoint.

OpenBSD is supposed to be used for network edge devices - firewalls, etc, in which SMP is not required.

If you want a Unix for your desktop - try Linux, or help out testing FreeBSD 5.0.

Its not about Theo "getting it together" ... no SMP is a design decision that has been made.

smash.

Re:Terrific...

[Walterk]

Here's my take on the matter, if you want a UNIX desktop go for NetBSD. It has SMP for i386 (and various other platforms), and kernel threads are on their way of being debugged. It has also had the non exec stack for about half a year now. It also has zero copy tcp features for enhanced TCP.

Seriously, why do people overlook NetBSD? It's about as secure as OBSD, and about as fast as FBSD. Ofcourse most of these features are in -current, and will be in 1.7.

Lack of a decent package manager always bothered me when looking at most linux distribution. Linux' NFS implementation is also seriously flacky (not trolling here).

No doubt this will go on as a troll, but NetBSD does all the things I want it to, both as a workstation and server.

Re:Terrific...

[ciph3rBSD]

There won't be, NetBSD 1.7, it will be NetBSD 2.0 :)

Re:Terrific...

[NerveGas]

SMP makes the kernel less secure? Wow. Gee. Yeppers, we must have seen a MILLION security holes in Linux from the SMP code.... (yeah, right.)

Simply claiming that it would make it more complex and less secure still doesn't excuse the fact that it's just about the only real, stable, robust operating system left that doesn't support SMP.

Re:Terrific...

[smash]

SMP makes the kernel less secure? Wow. Gee. Yeppers, we must have seen a MILLION security holes in Linux from the SMP code.... (yeah, right.)

Simply claiming that it would make it more complex and less secure still doesn't excuse the fact that it's just about the only real, stable, robust operating system left that doesn't support SMP.

They're called race conditions. Anyway, regardless of whether or not it directly adds to the security risk, it makes the code more complex and difficult to audit, which reduces the amount of developer time available for auditing the rest of it - and there has definately been more security holes in Linux than OpenBSD - maybe featuritis is a contributing factor?

SMP simply is not a requirement for OpenBSD's niche. Besides, if you want SMP in OpenBSD, there's nothing to stop you forking it and building your own...

smash.

Re:oh ya, right

[t0ny]

no, I dont knwo that Im wrong. What I am saying is that people are praising one group for announcing a clean-up of their code, and ridiculing another.

Well, like I say, there is nothing more American than a good ol' fashioned double-standard.

Re:oh ya, right

[Loki_1929]

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.

You're sort of right

[anonymous cupboard]

Theo doesn't like to enable functionality on OpenBSD until he is fairly certain that it is secure. The process isn't perfect, for example, he has also seen the OpenSSH problems - but most of the time it works.

Forget about security through obscurity, this is security through paranoia. Sometimes, it is justified.

Runtime Decompression??

[eaglesnax]

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

Re:Why not Windows

[anonymous cupboard]

AIX is quite big as an external server platform, probably because of the high-end IBM Web products. It is considered to be fairly secure (certainly a better rep than Solaris) and some banks run their online banking services from it.

If you really want security, go and buy OpenVMS!!!!

Re:An exercise in futility

[lux55]

Good point about success measurement. OpenBSD was also the project that gave us the widely used OpenSSH. OpenBSD may not get the commercial backing Linux does, but it's still an important project which has produced features and ideas that other projects now benefit from as well.

Re:oh ya, right

[Tony-A]

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 ;-)

Re:Why not Windows

[allanc]

Well, number one, from the article:

The i386 is not capable of doing per-page execute permission. At most it is only capable of drawing a line through the address space, by limiting the code segment length (using the code segment register). So we can say, "from 0 to this point is executable" and "from that point on to the end of userland is not executable". This sucks, but it is the best we can currently do. We can protect the stack, and not much else.

which means that the only architecture Windows really runs on nowadays is piss-poor for implementing these measures.

Number two, I'm guessing, is that these are apparently fairly new ideas, so the Windows guys might just not have thought of them. Or, if they did, they might have incurred more of a performance hit than Microsoft was willing to take. Or maybe doing it under Windows would have required a complete recompile of all Windows applications. There are many possibilities.

--AC

Re:oh ya, right

[anonymous cupboard]

You're Astroturfing, right?

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.

Uses

[JimmytheGeek]

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.

Re:We are much more secure

[evilviper]

I can still exploit root on an OpenBSD machine with a crappy CGI

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.

BSD security is a myth

[geekoid]

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.

Re:Why not Windows

[geekoid]

"Windows was meant to be more of a "user-friendly consumer OS"."

that is no reason for it, that is just an excuse.

Windows is written to meet demand, not to exceded it. It could be secure, but they really don't care.

There starting to care, unfortunatly they would have to do a real redsign from the ground, by people who where experts, and had never seen any other windows code.

Do you think Car companies would care about safety if you were forced to sign a waiver and couldn't sue them? Hell, you'ls be lucky if the brakes worked after a month.

I'd rather hace to do an update once in a while by hand, then an update every couple of months with push button convience.

Thank you OpenBSD!

[mrs clear plastic]

Thank you OpenBSD!

Hardware

[octogen]

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.

Me too!

[Erris]

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.

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.

I use OpenBSD often, but...

[burbilog]

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.

Re:I use OpenBSD often, but...

[RazzleDazzle]

http://www.deadly.org/article.php3?sid=20030206041 352

Re:Why not Windows

[You're All Wrong]

"
but likely those machines wont be used for external servers
"

is a bit of a red herring. To be secure a server has got to be secure against rogue internal clients too. Do you trust every X client to be able to handle rogue events from every X server? There have been some pretty shoddy X servers out there, particularly in the Windows desktop world, and I certainly wouldn't trust them.

YAW

This sounds like a job for...Passport!

[0x0d0a]

Too bad the Open Source community has no equivalent...

Re:Why not Windows

[Penguinoflight]

Well, up to the point of thousands of testers, windows has a better market, but it's only because windows is so popular, not because it's a closed source project. Back when linux 2.4 was being worked on, there were literally thousands of people testing it, including people with skills. Probably over half of microsoft's "beta testers" were just in there to get a cheaper copy of the full version.

And, as far as users go, it's even worse. With so many people just using MS Word, Outlook, IE... Oh wait, Microsoft STILL hasn't got any of those programs secure. :-)

More Examples (incl. Linux)

[modulo]

Some others that have come up for discussion before (?) are:

Trusted Solaris

and

Pit 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.)

HTTP? IRC!

[Fefe]

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

Re:HTTP? IRC!

[grub]

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.

Re:Now th

[grub]

I think finally I am gonna try OpenBSD. Does anyone know what hardware requirements it has

Currently supported hardware can be found here. Enjoy, it's a damn fine OS.

Different stacks...

[wowbagger]

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.

OpenBFD

[PegQuin]

OpenBFD

Re:Why not Windows

[FroMan]

Moderations: 40% Flamebait, 20% Insightful, 30% Funny
I guess it was humorously insightful flamebait...

The other 10% was "Underrated" or "Missing"?

Re:We are much more secure

[jolan]

I can still exploit root on an OpenBSD machine with a crappy CGI.

Really?

www 2224 0.0 0.0 1188 1760 ?? Ss 7:01PM 0:02.24 httpd: parent [chroot /var/www] (httpd)

But it doesn't run as root and it's chroot'd...

Good luck getting root!

LIDS makes more sense than a non-exec stack

[hopeless case]

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.

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 /usr/sbin/httpd the ability to bind to port 80, and no other root powers.

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.

Re:Why not Windows

[dohcvtec]

I doubt that patching openbsd is at easy as opening the default browser, clicking on the Tools toolbar and click Windows Update
Right you are, and as you say, it does have more to do with priorities, not only with the manufacturer, but with the end-user. There are very few people I know of who even realize that security is an issue to be aware of. As mind-numbingly easy as Windows Update is to use, I've tried and tried to get everyone I know to simply click on Windows Update once a week. Nobody does it. Same thing with antivirus software - they just won't do it.

Re:Why not Windows

[vmfedor]

Because security isn't Microsoft's main concern. They make desktop operating systems primarily and they do a damned fine job of it. FreeBSD is a server operating system. It's like comparing apples to oranges.

Re:Why not Windows

[jackbox]

"Windows was meant to be more of a "user-friendly consumer OS"."

that is no reason for it, that is just an excuse.

Sorry, but I really think that's a knee-jerk reaction to the issue. I don't want to get on a soapbox to defend Microsoft, but part of MS's goal is, in fact, to meet market demand.

Chevys and Rolls Royces are aimed at different markets; that doesn't make Chevy's relative lack of reliability an "excuse." It's a trade-off, and the market chooses what to pay for and what not to.

Yeah, MS is in a bad technical corner because in order to meet market demand they've had to maintain compatability with older software components that were never, ever intended to be put on a public network. I certainly wouldn't call that merely an "excuse." If they pulled all that compatability stuff out, who would buy it? How many people here can name GREAT products that failed - and now don't exist at all - because of the market?


Sidenote: I think often about how when Jimmy Carter was President, he wanted to invest significant money in researching alternate forms of energy: solar, wind, etc. He was criticized and ridiculed. Decades later, Americans still drive gas guzzlers. Our petroleum-based lifestyle (read: desire for ease of use) has helped create a political situation (and a security situation) that makes us resent and fear some of the very people we are now highly dependent upon. And we may go to war because of it.

Seems to me the root of the problem is way too big for even Microsoft to be able to take all the blame.

what's all this hype about?

[Phacka]

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.

Re:oh ya, right

[t0ny]

The exploit you talk about is very old, and has been posted here. And what is more is, its not even a MS problem; its a problem of third-party programmers leaving vulnerabilities in their applications. It was already discussed here http://slashdot.org/article.pl?sid=02/08/06/182825 6&mode=thread

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?

Oh ya, Im a troll

[t0ny]

nice hometown refs. I get modded down and labeled a troll because I state the bias and double standard around here.

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.

Re:Oh ya, Im a troll

[t0ny]

see this...

http://forums.techguy.org/t111580/scff29c 563a81ff7b6a51de5cd787fdc9.html

and this...

and this (see especially #4, a long running problem)...

http://www.cert.org/summaries/CS-96.0 4.html

a surpisingly unbiased article from a unix guy here...

http://www.itworld.com/nl/unix_sec/082320 01/

Re:oh ya, right

[t0ny]

No, this isnt astroturf. I honestly dont care what anyone else thinks. I just work with MS products, work in computer security, and have been doing this for a long time.

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.

Re: Why not Windows

[natmakarvitch]

... because 'secure operating system' is qualitative, and 'lot money and programmers' is quantitative (one million monkeys ... typewriter ... you know)

Re:Why not Windows

[Black Copter Control]

I doubt that patching openbsd is at easy as opening the default browser, clicking on the Tools toolbar and click Windows Update.

If OpenBSD had as many serious security patches as Windows, somebody would probably get around to writing something like that :-). Then again, if it was as buggy as Windows, it wouldn't be OpenBSD.

Redhat has their RedHat Network which does easy updates. I have my own package that I use instead (mostly 'cause I'm used to it). If I'd wanted to, I could probably modify it to work with openSSh but, so far, it really hasn't been worth it (my OpenBSD box is used as a firewall, so it has a lot less loaded on it to begin with (on a 500MB disk) -- thus a lot less to patch.

When playing with servers, patching a system is often much more than just blindly installing the latest patch. (especially with windows). One also has to check to make sure that the patch doesn't also break something critical. From an operatonal point of view, there isn't much of a difference between a system brought down by the most recent worm and one brought down by the most recent patch.

Of course, unlike the Open Source world, you almost never have the option of back-porting the most recent patch to your system if the 'product updates' included with a patch break your software. (actually, acording to the most recent M$ EULA, you may not even have the right to wait until you can fix your software to survive the latest patch).

OpenBSD and 32bits UID

[^BR]

% grep uid_t /usr/include/sys/types.h
typedef u_int32_t uid_t; /* user id */
% 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.

Windows more secure than OBSD is useful to public

[leonbrooks]

I would venture and say that Windows is closer to being secure than OpenBSD is to being useful to the general public.

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.

Re:Why not Windows

[pstemari]

Well, that's not exactly true. x86 architecture does support execute seperate from read, but it's on a segment basis. If you move away from a single 32-bit segment that emulates a flat memory model and move to multiple 32-bit length segments (i.e. 48-bit addressing), you can quite easily support both read-only and read+execute memory.

However, a non-flat address space doesn't play nice with traditional kernal designs, and to the best of my knowledge no one has ever actually implemented the type of operating system that x86 was designed to support.

Re:HTTP? IRC!

[drinkypoo]

How does ircing from a CVS repository machine invite being backdoored and trojaned, unless you are doing it as a user with write permissions to the repository?

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.

Bad engineering management....

[anonymous cupboard]

is my own view of MS. They really rush stuff out which is still clearly bug ridden. They also have big problems locking systems down. Remember that memo that was leaked about the issues as to which services were needed for what functionality?

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.

Re:Bad engineering management....

[t0ny]

well, as amazing as it may be for you to hear, the network and sites I maintain actually DO work, and we use MS for pretty much everything. Mp>For some strange reason, Exchange seems to run without me needing to see the source code... I still cant figure that one out!

My point is, YOU may have reasons to need the source code, but 99% of the people who use MS's products don't (and wouldnt know what to do with it if they could). THAT is why MS and Win95 made computing what it is- it took computers out of the hands of the technological elite, and put it in the hands of the people. I didnt really mean to make it sound so grandiose, but you get my point. They made computers accessible to regular people.

So a lawyer can just be a lawyer w.o needing to be an IT expert, and a nurse can just be a nurse w.o needing to be a unix guru. And instead of having to pay people to configure IRQs and DMAs and all that crap by hand, they made setup and installation easy. In that regard they are still way ahead of linux (even tho some distros have made big strides in the last year).

so we just have different ideas of what makes computing good. I happen to think that reaching a mass market it good for making progress. You think that having a secure niche markey makes something great. Who is right? I dont know. Bill Gates could buy Linus Torvald's family for the last four generations just to have them clean his bathroom, though.

Re:Bad engineering management....

[anonymous cupboard]

Yes, the networks and sites you maintain may sometimes work but are they owned by script kiddies and are launching DDOS attacks? Would you even know?

For some strange reason, Exchange seems to run without me needing to see the source code... I still cant figure that one out!

Um, what about all those times when the DB is trashed and the backup will not restore. This generally happens after you find out that replication didn't work.

Win95 didn't really takes computers out of the hands of the 'technological elite'. That was Win98 which was somewaht more stable. With WIn95, you said goodbye to the mainfarme expert and found yourself buying a PC expert instead.

It sounds very much like you never ran somthing like an autoconfigure on a big machine. Guess what? It found all those IRQs and DMA channels for you.

Believe it or not those very professions you mentioned were already served by systems that didn't require professionals to use them. The Nurse didn't want a system to go down every five minutes while inputting patient data and the lawyer didn't want case files to be opened by all and sundry. Maybe it helped them at home run new games, but it certainly didn't do much in the workspace. In any case, you are right in one respect, it took the machine out of the hands of the technological elite and put them in the hands of a "Minesweeper Consultant and Solitaire Expert".

Gates and Ballmer may be rich, but this did not come from technological prowess, it came from being a little too hard in the business.

Now even governemnts are realising the fallacy of choosing expensive, closed source implementations. Software licenses are expensive and the "Bill and Steve Show" want to push us towards a rental model. This is very expensive and their customers are seeing the danger. Server licenses are just too expensive (you pay for the base system that you are running on plus per seat for the server). As I said, this now makes Microsoft as expensive as the big boys, but without the depth of support.

Support for major systems is expensive. I have seen problems that require the resources of a major company to fix. Do you really want to be dependent upon a single company with no reputation for customer service to get you going?

I like plurality, worms and viruses have harder times when you have multiple architectures. However, I really don't like a closed source server - it can close me out of fixing it. It seems India and Germany seem to agree. Interestingly enough that although we know that India is tainted by corruption, Linux can't pay bribes, because it isn't a single company.

Re:Bad engineering management....

[t0ny]

Yes, the networks and sites you maintain may sometimes work but are they owned by script kiddies and are launching DDOS attacks? Would you even know?

um, ya. I think I would know if we couldnt get to the internet, and you would have to be a complete fool to leave your network wide open to the network anyway.

I think the problem may be that most people (and possibly yourself, although I dont know your situation) do not understand networking best-practices. I dont care how supposedly secure any operating system is, but there is no way in hell I will allow it onto the internet without a firewall. So for any system to get "0wNzed", the need to get past the firewall first. Not impossible, but few things are impossible, only improbable.

Win95 didn't really takes computers out of the hands of the 'technological elite'. That was Win98 which was somewaht more stable. With WIn95, you said goodbye to the mainfarme expert and found yourself buying a PC expert instead.

I used to support Win95, and not only was it (Win95 OSR2, anyway) a great deal more stable than Win98, but it benchmarked faster. The sons of Win95 each got slower relative to the parent, because it used the same codebase but added bloat. From your statement its aparent you dont really know much about MS products, from a support standpoint. Just because you say it (or read it on Slashdot) doesnt make it true.

It sounds very much like you never ran somthing like an autoconfigure on a big machine. Guess what? It found all those IRQs and DMA channels for you.

No, I didnt, nor was that even what I was talking about. I was refering to the computers ordinary people used. I dont know about you, but nobody on my block had an AS400 in their house.

The Nurse didn't want a system to go down every five minutes while inputting patient data and the lawyer didn't want case files to be opened by all and sundry... etc

Can you start dealing with concrete things rather than just spewing anicdotes? You act like someone can hack into a network by mindpower alone. As far as networking goes, Win95 is fairly secure; at least enough to keep a casual person out.

Do you really want to be dependent upon a single company with no reputation for customer service to get you going?

I hope you arent refering to Microsoft. I get excellent customer service from them. Between being able to find the answers to just about any problem on Technet, I did need to call them a few times, and one time they had a patch that didnt make it into technet yet (and emailed me the patch the next day), and twice they flew somebody in to look into the problem. So as far as MS goes, I havent really seen a problem with tech support or customer service. Maybe little Johnny calling in because he cant get Quake to work wouldnt get the same level of service, but little Johnny didnt exactly rule out what was and wasnt the problem on his own and determine if it WAS the OS. Thats called being an IT pro.

It seems India and Germany seem to agree

I worked for a few international companies, and on average the products that come out of German and India are very sub-par, compared to US standards (for example, SAP has many pending lawsuits). If you want to throw your hat in with them, go right ahead. I'll stick with American IT myself, I dont have time for dealing with the bugs, bad work ethics, and language barrier.

And you may want to look at my posting "My Operating System finances Al-Queda"

http://slashdot.org/comments.pl?sid=527 42&cid=5225058

When you look at the long term, your fanaticism against Microsoft may actually be doing great harm to this country. I just have a problem with habitual complainers, who bitch about everyone's perceived faults, but really do little to suggest solutions. Its just too easy to complain, but a lot of hard work to come up with actual solutions.

Re:Bad engineering management....

[anonymous cupboard]

Um, everyone at home has a firewall and DMZ? If you have one, is it correctly configured? In a professional enviornment do you have just one operating system? Interesting.

In a commercial environment, I mix system types in such a way that an exploit through one isn't an exploit for another. Somewhere behind the OpenBSD/Linux/whatever, you may even find Win2K or XP. From biology we should know that monoculture is dangerous and a lack of diversity increases susceptibility to disease.

In any case, how come that one of the problems my non-computing friends have is being tricked into downloading stuff at home by IE. MS doesn't do this but they make it very, very easy for otherpeople to do so. Why didn't Win95 and onwards create an administrative as well as a user login?

You could download as a user but you could only install as an administrator. The idea of privilege separation doesn't even seem to be on XP home as shipped.

I started working with Microsoft software in the early days. I even used Microsoft Windows 1.0. It took MS until 3.1 to have it slightly useful, 3.11 was better and Win95 better still. Why did Microsoft screw up for so long?

In the days when Windows was cheap, I didn't really care so much about support. Sorry, if I have paid more for the system and again for support, I expect something better. If I pay a lot for 24x7 support and a problem occurs, I want a workaround by next business day and a fix within a week. Otherwise, it will be in the papers and the IT dept would be out of the job. Understandably, that client of mine does not use MS in critical areas like the production servers.

I like your quote about SAP. I think you will find that every major supplier of commercial software has pending law suits. Of course the six weeks min holiday, etc., in Germany represent an appalling work ethic. In India, well you will find a lot of Microsoft stuff coming from there - I agree I don't have time for the bugs, etc. In any case, I was referring to the countries' respective governments.

I remember the post "My Operating System finances Al-Queda", I thought it was a splendid troll and very funny. Sorry, I didn't realise that it was serious. Still it gives an alternative to "My operating system stops warships dead in the water - Ours!!"

Lastly, haven't you heard about Foreign Sales Companies? Microsoft pays very little taxes anyway and all foreign profits are filtered through offshore companies as a tax avoidance scam.

Re:Why not Windows

[foxed]

Because if the typical Slashdot reader doesn't know the difference between an adjective (good) and an adverb (well), just how dumb must Microsoft employees be?

The "Vision" in BSDs Security features.

[PFAK]

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.

A good installer from Debian? Yes.

[leonbrooks]

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.