Re: Loose Cannon-dian

On Sep 13, 10:30 am, johnwalla...@xxxxxxxxxxx wrote:
On Sep 12, 1:38 pm, koeh...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Bob





Koehler) wrote:
In article <gad67a$apc$0...@xxxxxxxxxxxxxxxxx>, Michael Kraemer <M.Krae....@xxxxxx> writes:

This doesn't answer my question.
The claim was that VMS is more secure than Unix,
and I asked for certifications to prove that claim.
But as far as I can see, VMS is just on par as
far as obsolete criteria are concerned (C2/B1),
and it is not certified at all for the more recent
common criteria.

   The problem is the asumption behind your question.  Just because
   VMS is more secure than UNIX does not prove tham somone bothered
   to write down a certification that covers the differences.

   Nor does the existence of a certification criteria make it the last
   and complete word on security.

Indeed. I'll ask the community again, what mechanisms do best
practices on various Windozes and Unixes have to prevent a resource-
exhaustion Denial of Service, one which on a properly managed VMS is
easily preventable, but which (from what I've seen to date) is
impossible to prevent on many other OSes. What do the Common Criteria
have to say on the subject, or is a resource exhaustion DoS a figment
of my imagination ?

On a desktop OS you probably don't care about this, and on a desktop-
derived server OS you probably can't care about this, but on a true
multi-tasking multi-user OS serving one or more business-critical
applications, it ought to be of more interest. If the underlying OS
doesn't have the necessary real-time resource accounting capability
built in, best for the industry if they keep quiet about it?- Hide quoted text -

- Show quoted text -

To answer your question, it is possible to do in UNIX too. For example
see http://www.freebsd.org/doc/en/books/handbook/users-limiting.html

This can protect you from simple resource exhaustion attacks, and
while that is cool it doesn't necessary make you any more secure. If
someone exploits a privileged program or the kernel to obtain root/
SYSTEM access then they can still DoS you back to the stone age, but
more likely they steal/modify your data which in almost all cases is
even worse than *just* disrupting a service.

So let me ask you what mechanisms VMS have in place to make it harder/
prevent buggy programs from being exploited?

On UNIX we have among other things:

W^X - Different vendors use different names, but the general idea is
that by default a page that is writable is not executable. The idea is
to prevent attackers from executing code in memory they control.

ASLR - Address space layout randomization. With W^X alone, overwriting
stack return address and returning into a library function would be
trivial. ASLR makes that much harder since the address of the function
the attacker wants to return to is not known to him.

Compiler hacks - Stack canaries/cookies etc, an overwriten return
address on the stack for example will be detected before the return
branch is taken.

"Even" Windows supports these features with DEP, Vista got ASLR, and
their compiler had the /GS switch for stack protection for quite some
time now.

Of course these features are not perfect. There are special cases
where they are trivial to by pass even. They do help, but the only
real solution to getting secure is to look for and fix security bugs
not trying to compensate by introducing features that makes it harder
to exploit them.

This is where UNIX has a real advantage and head start.. A LOT of
people have been looking for and killing UNIX bugs for a very long
time. Look at the bugs being discussed here, I doubt that you'll find
that simple and exploitable stack overflows in any BSD, modern version
of Solaris or even Linux (there are default binaries with simple stack
overflows, but I'm talking about suid/sgid etc binaries where a bug
potentially leads to a system compromise)

Just in case your counter argument is that we only found 3 bugs and
argue that you can name more kernel vulns published in Linux this year
alone... Keep in mind that we are only 3 people looking at it for fun,
and only when we got a few minutes / hours to spare from doing "real
work". And our bug count is up to 5 reported bugs to HP now..

.

Relevant Pages

  • Re: Loose Cannon-dian
    ... TCPIP stack or anything ported from Unix is riddled with bugs and buffer ... overflow risks because it is not really "native" VMS software. ... were code reviews, walk-throughs, programming standards (including ...
    (comp.os.vms)
  • Re: Loose Cannon-dian
    ... TCPIP stack or anything ported from Unix is riddled with bugs and buffer ... overflow risks because it is not really "native" VMS software. ... were code reviews, walk-throughs, programming standards (including ...
    (comp.os.vms)
  • Re: Loose Cannon-dian
    ... The claim was that VMS is more secure than Unix, ... real solution to getting secure is to look for and fix security bugs ...
    (comp.os.vms)
  • Re: Loose Cannon-dian
    ... I'd be willing to bet there was nobody from the VMS group at the DEFCON ... TCPIP stack or anything ported from Unix is riddled with bugs and buffer ... It isn't Unix's fault that there are bugs in VMS. ... were code reviews, walk-throughs, programming standards (including ...
    (comp.os.vms)
  • Re: unix price compare
    ... > 2003 are instrinsically more advanced than VMS or UNIX. ... > in more secure operating systems e.g. OpenBSD, SE linux, Adamantix, etc. ... google on DEFCON 12. ...
    (comp.unix.solaris)