DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; To throw this topic back on course, at least for a moment, I received an OpenVMS Security Bulletin email from HP yesterday afternoon. The SMGRTL stuff was in there....

+ Reply to Thread
Page 34 of 35 FirstFirst ... 24 32 33 34 35 LastLast
Results 661 to 680 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: Loose Cannon-dian

    To throw this topic back on course, at least for a moment, I received
    an OpenVMS Security Bulletin email from HP yesterday afternoon. The
    SMGRTL stuff was in there.


  2. Re: Loose Cannon-dian

    In article , Michael Kraemer writes:
    >
    > and which certification suite addresses these concerns
    > and what is VMS's ranking in this context ?


    What makes you think someone bother to write one? He was done
    counting the paticles of sand on the beach?


  3. Re: Loose Cannon-dian

    Bob Koehler schrieb:
    > In article , Michael Kraemer writes:
    >
    >>and which certification suite addresses these concerns
    >>and what is VMS's ranking in this context ?

    >
    >
    > What makes you think someone bother to write one? He was done
    > counting the paticles of sand on the beach?
    >


    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.


  4. Re: Loose Cannon-dian

    In article , Michael Kraemer 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.


  5. Re: Charon-VAX "upgrade" (was DEFCON 16 and Hacking OpenVMS)

    on 4-9-2008 6:05 Tom Linden wrote...
    >
    > http://h71000.www7.hp.com/openvms/sr...-emulator.html
    >
    > Of course, if you don't have it under maintenance I suppose it might
    > not be necessary, at least it would never be apparent.


    Sorry been (put) away for a while.

    This issue has been beaten to death before:

    With CHARON(-VAX,-AXP) you use your existing VMS license. HP will allow
    you to transfer this to the CHARON instance provided you slip'em the $$
    associated with the so called Transfer License. This is all arranged so
    you do not violate the terms of your original license, where the fine
    print says you only may run it on the VAX of Alpha that it came with.

    As an additional item, any SW maintenance contracts remain valid,
    although getting new bugs recognized and fixed requires you to reproduce
    them on a *real* VAX/Alpha.

    /Wilm

  6. Re: Loose Cannon-dian

    On Sep 12, 1:38 pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article , Michael Kraemer 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?

  7. Re: Loose Cannon-dian

    On Sep 13, 10:30*am, johnwalla...@yahoo.co.uk wrote:
    > On Sep 12, 1:38 pm, koeh...@eisner.nospam.encompasserve.org (Bob
    >
    >
    >
    >
    >
    > Koehler) wrote:
    > > In article , Michael Kraemer 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 quotedtext -
    >
    > - 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/...-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..


  8. RE: Loose Cannon-dian


    > -----Original Message-----
    > From: bugs@signedness.org [mailto:bugs@signedness.org]
    > Sent: Monday, September 15, 2008 6:37 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: Loose Cannon-dian
    >
    > On Sep 13, 10:30 am, johnwalla...@yahoo.co.uk wrote:
    > > On Sep 12, 1:38 pm, koeh...@eisner.nospam.encompasserve.org (Bob
    > >


    [snip..]

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


    Well, I will not comment on the other Unix's, but Red Hat publishes
    5-20+ security patches *per month* on its web site. Reference:
    https://www.redhat.com/archives/enterprise-watch-list/ (click on
    thread for each month and add them up - feel free to go back as far
    as you like).

    As I stated before, no OS is perfect (and that includes OpenVMS), and
    everyone here appreciates those who identify potential issues, but
    imho, it remains to be seen just what the other bugs you found are and
    the criticality of them.

    However, as I said, if there are issues, then of course, they need to
    be addressed.

    As a fyi, to your questions, if you would like a better understanding
    of OpenVMS security arch, then here are a few public doc pointers:

    http://h71028.www7.hp.com/ERC/downlo...A0-2896ENW.pdf (overview)

    http://h71000.www7.hp.com/doc/os83_index.html (See security doc's)


    Regards

    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-254-8911
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.






  9. Re: Loose Cannon-dian

    In article <1cddb0fc-c644-4c38-9d33-0825a9a4b269@s50g2000hsb.googlegroups.com>, bugs@signedness.org writes:
    >
    > To answer your question, it is possible to do in UNIX too. For example
    > see http://www.freebsd.org/doc/en/books/...-limiting.html


    In my experience, that depends very much on which UNIX you're using.
    Since you site a FreeBSD site, I assume I can do it on FreeBSD.

    But I've worked with other BSD variants where I couldn't.


  10. Re: Loose Cannon-dian

    In article <1cddb0fc-c644-4c38-9d33-0825a9a4b269@s50g2000hsb.googlegroups.com>, bugs@signedness.org writes:
    >
    > So let me ask you what mechanisms VMS have in place to make it harder/
    > prevent buggy programs from being exploited?


    On VMS, even if you have a fully priviledges account, you don't
    automagically get to exhaust any resource other than disk space.
    For all the others you have to add code to raise your limits.

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


    A great many hardware platforms won't support that, no matter what
    UNIX tries to do about it.

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


    A lot of people have been looking for and killing VMS bugs for a
    long time, too. There just haven't been as many. Even back in the
    day when "get a VAX" was The Solution to almost every compute problem
    and VMS was all over the networks, there weren't many.

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


    The idea that quality software is impossible is one that I
    completely reject.


  11. Re: Loose Cannon-dian

    On Sep 15, 5:42*pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article <1cddb0fc-c644-4c38-9d33-0825a9a4b...@s50g2000hsb.googlegroups..com>, b...@signedness.org writes:
    >
    >
    >
    > > So let me ask you what mechanisms VMS have in place to make it harder/
    > > prevent buggy programs from being exploited?

    >
    > * *On VMS, even if you have a fully priviledges account, you don't
    > * *automagically get to exhaust any resource other than disk space.
    > * *For all the others you have to add code to raise your limits.
    >


    Well obviously you can do that on UNIX too (change root's resource
    allocation).. But like you are pointing out if the attacker gets your
    admin account well then he can just raise his limits.... Which was
    exactly my point.. I pointed out that UNIX got that sort of resource
    allocation features too, but that it is not exactly a revolutionary
    security feature and when your security is breached and this
    particular feature is circumvented, getting DoS'd is usually the least
    of your concern..

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

    >
    > * *A great many hardware platforms won't support that, no matter what
    > * *UNIX tries to do about it.


    Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha,
    Intel-64 and even i386 with some hacks to get around hardware
    limitations. Infact I think all decent sized open source UNIX kernel
    supports it to some extent, in many cases even on platforms where
    hacks are required to get around hardware limitations. Solaris also
    supports it, if I recall correctly TRU64 also used to have non-exec
    stack until they changed it to support java and other crap (see java
    is EVIL)

    So most "UNIX" you still see in production environments can actually
    do it..

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

    >
    > * *A lot of people have been looking for and killing VMS bugs for a
    > * *long time, too. *There just haven't been as many. *Even back in the
    > * *day when "get a VAX" was The Solution to almost every compute problem
    > * *and VMS was all over the networks, there weren't many.
    >


    The 3 of us have been doing this for about 10 years (looking for
    bugs), and we attend a lot of conferences around the world for people
    like us every year. So we know a fair amount of people in our
    "industry" and so far only one have said that at some point in time he
    thought about having a look at OpenVMS security (but he didn't). Out
    of the entire lot we know in the industry we can't name one who have
    actually looked at it... People were looking at in the 80s, we know
    this, we read the old hacking zines at textfiles.com... But.....

    There are new vulnerability classes and exploitation techniques being
    published all the time... Think Moore's law here.. and you'll get an
    idea how fast it evolves. I'm sure the people trying to break VMS
    security in the 80s were really good for their time, they did not
    however have the benefit of 20 years of published research we had
    since that. Take the format string bugs in finger, the technique to
    expoits those bugs were only made public around 2001. Maybe I would
    have agreed that VMS was cool from a security point of view 10-20
    years ago, but today compared to the competition? I don't think so.

    If anyone had a serious go at finding vulns in VMS in the last 5-10
    years, our defcon and our new bugs would have been fixed a long time
    ago.

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

    >
    > * *The idea that quality software is impossible is one that I
    > * *completely reject.


    Well nothing is impossible I guess. But when actual rocket scientists
    (NASA, ESA, whatever the russians call themselves) keep getting
    things like unit conversions wrong and it gets past what I would
    assume is fairly rigours QA (at least one would hope so considering
    the costs of blowing these things up...) I think you are going to have
    to wait a long time before your average programmer create quality
    softare without security bugs in something as complex as an operating
    system.

    Pretty much what we been saying all along is "if you don't look for
    these things then you are not going to find them but that does not
    mean you are secure".


  12. Re: Loose Cannon-dian

    In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes:
    >
    > Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha,
    > Intel-64 and even i386 with some hacks to get around hardware
    > limitations.


    Are you claiming the UNIX kernel examines every instruction to see
    if it was read from data space? Just separating and marking the
    code read-only doesn't prevent executing writeable data space.

    It's been a long time since I saw an OS with both a user interface
    and default writeable code pages during execution. It was from M$.


  13. Re: Loose Cannon-dian

    On Sep 15, 11:36 am, b...@signedness.org wrote:
    > On Sep 13, 10:30 am, johnwalla...@yahoo.co.uk wrote:
    >
    >
    >
    > > On Sep 12, 1:38 pm, koeh...@eisner.nospam.encompasserve.org (Bob

    >
    > > Koehler) wrote:
    > > > In article , Michael Kraemer 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
    > seehttp://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..


    Are we on the same wavelength here? Hopefully yes. Decent OSes whose
    heritage is multiuser multitasking tend to have at least some level of
    protection against resource exhaustion issues. Readers (if there are
    any left) are still waiting for the answer for OSes whose origin is
    desktop (you know the one I mean).

    If folk can get root/SYSTEM access there are indeed much more serious
    things to worry about than resource exhaustion (loss of data,
    unintended export of data, etc), but if users can get unauthorised
    execution of unprivileged code and cause a resource exhaustion DoS,
    that could be inconvenient too.

    It's a shame VMS on Alpha didn't do anything useful with "fault on
    execute" in the PTE. But it's now largely irrelevant, because Itanium
    does (iirc) have the "non executable pages" stuff. And AMD64 certainly
    does.

    ASLR is something mentioned earlier in this thread (I thought?).
    Afaict the whole ASLR band-aid/concept is foreign to (and incompatible
    with) VMS's use of transfer vectors so that applications can if they
    so wish call the same runtime libraries at the same addresses
    regardless of version changes. The code itself may move, but the
    transfer vector deliberately stays at the same place, so what's the
    point in randomising anything? In VMS land this kind of design
    decision is called "investment protection", and it's an OS design-time
    decision which made sense back then, and arguably still makes sense
    today (just ask anyone who's experienced the SxS nightmare on Windows
    when you need to support one app version on multiple OS versions).
    Same as the decision to include assorted resource quotas is pretty
    much set in stone when the OS is designed (you can choose to enforce
    them or not, or set sensible values or not, but if they're not
    architected right they can't be retrofitted externally).

    In respect of your later post: re who's been looking at VMS security
    and when: did you know that the VMS listings were widely available
    (for free, iirc) inside DEC, and were available for a relatively small
    fee to customers (systems houses, etc) outside DEC ? They may still be
    available, I don't know. And did you know that VMS Internals and Data
    Structures courses for employees and outsiders were relatively common
    and sometimes went into great detail, sometimes even more than is in
    The I+DS Book? Consequently the number of people who have seen inside
    VMS is perhaps larger than you think, and the number of *interested*,
    *competent*, *knowledgeable* people who've looked inside in the past
    is almost certainly larger than you seem to imagine. Whether that's
    helped make VMS more secure is a more difficult question to answer;
    the people that may know are unlikely to comment here. You have
    yourself found holes which ought not to have been there, but have
    other holes been fixed as a result of folks poking around in the
    source listings? It's like the "peer review" argument for FOSS isn't
    it?

    One final note re: "you are going to have to wait a long time before
    your average programmer create quality
    softare without security bugs in something as complex as an operating
    system. "

    Seems very fair. From which I conclude that folks who care about
    quality, security, etc would be well advised not to use an OS
    architected by (not just written by) "average programmers". The same
    also goes for compilers, runtime libraries, and the like. Others may
    well draw a different conclusion

    I can't comment on the current state of DEC/CPQ/HP compilers and
    runtimes but those I have known in the past have never lacked the
    facilities I've needed (or the facilities my customers have needed)
    and have often set the standard for the industry to compare with
    (Fortran and Ada were known to me, but there were others too. Then
    there was VAX C, which is probably best forgotten). Again with
    compilers and runtimes we see the importance of *architecture* as well
    as implementation. MS have finally realised that a common language
    runtime might be a bright idea. VMS shipped its common language
    runtime (based on the language-independent "calling standard", common
    structure definition language, and the like) back in 1978, and common
    code generators (compiler backends etc) were also in early use.

    A decent architecture doesn't prevent rubbish code, but a rubbish
    architecture can easily make rubbish code more dangerous.


  14. Re: Loose Cannon-dian

    In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes:
    >
    > The 3 of us have been doing this for about 10 years (looking for
    > bugs), and we attend a lot of conferences around the world for people
    > like us every year. So we know a fair amount of people in our
    > "industry" and so far only one have said that at some point in time he
    > thought about having a look at OpenVMS security (but he didn't). Out
    > of the entire lot we know in the industry we can't name one who have
    > actually looked at it... People were looking at in the 80s, we know
    > this, we read the old hacking zines at textfiles.com... But.....


    So, you're behind the times, trying to catch jup, and making broad
    claims about the state of security in an OS you're still learning?

    That's not a lot of credibility where I come from.

    >
    > There are new vulnerability classes and exploitation techniques being
    > published all the time... Think Moore's law here.. and you'll get an
    > idea how fast it evolves. I'm sure the people trying to break VMS
    > security in the 80s were really good for their time, they did not
    > however have the benefit of 20 years of published research we had
    > since that. Take the format string bugs in finger, the technique to
    > expoits those bugs were only made public around 2001. Maybe I would
    > have agreed that VMS was cool from a security point of view 10-20
    > years ago, but today compared to the competition? I don't think so.


    20 years of published research on how to hack into poorly designed
    and/or implemented systems may not apply to a system mostly ignored
    by those researchers.

    > Well nothing is impossible I guess. But when actual rocket scientists
    > (NASA, ESA, whatever the russians call themselves) keep getting
    > things like unit conversions wrong and it gets past what I would
    > assume is fairly rigours QA (at least one would hope so considering
    > the costs of blowing these things up...) I think you are going to have
    > to wait a long time before your average programmer create quality
    > softare without security bugs in something as complex as an operating
    > system.


    I'm not about to accuse VMS Engineering of being "average
    programmers". OS complexity is often a result of poor design. What
    I can see is that UNIX and Windows security design makes it easy
    to screw up. VMS security design makes it easy to get things right
    (more about that below). And lots of stiudies have shown that
    rigorous QA actaully can become an excuse for poor work. ("QA will
    catch it if it's wrong." "It must be good enough, QA passed it.")

    Sure, you can get things right in UNIX and you can screw up in VMS,
    but you don't get a feel for impact of design decisions all that
    fast.

    SUID, SGID, and all or nothing privileges have been tripped over so
    many times as to make thier inherint difficulties obvious. VMS
    didn't have the equivalent of SUID or SGID for a long, long, time,
    and implemented it in a way that made it easy to use, optional
    to turn on, and completely unjustified to use it like SUID 0. A
    lot of modern UNIX now have finer grains of privilege, like VMS has
    always had, but when you use a file's mode to SUID 0, what good did
    that granularity do you?

    These are just some of the reasons that people who did look for
    vulnerabilities didn't find many, and soon chose easier targets.

    I could go on, but you're not listening.


  15. Re: Loose Cannon-dian

    In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    >In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes:
    >>
    >> The 3 of us have been doing this for about 10 years (looking for
    >> bugs), and we attend a lot of conferences around the world for people
    >> like us every year. So we know a fair amount of people in our
    >> "industry" and so far only one have said that at some point in time he
    >> thought about having a look at OpenVMS security (but he didn't). Out
    >> of the entire lot we know in the industry we can't name one who have
    >> actually looked at it... People were looking at in the 80s, we know
    >> this, we read the old hacking zines at textfiles.com... But.....

    >
    > So, you're behind the times, trying to catch jup, and making broad
    > claims about the state of security in an OS you're still learning?
    >
    > That's not a lot of credibility where I come from.


    I think you're making good points, but this is basically an argument you
    can't win. Their position is that they didn't know much about the system,
    didn't try very hard, and found some vulnerabilities, at least one of which
    has now resulted in a MUP to fix a 20+ year old problem. At this point
    we're better off saying "thank you, and keep up the good work" than in
    arguing from first principles about how the better engineering and the
    internal code review and the good design means that there are fewer
    vulnerabilities than in other systems which have been bashed on harder
    than VMS has during, oh, the entire lifetime of the commercial internet.

    -- Alan


  16. Re: Loose Cannon-dian

    On Sep 15, 9:51*pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article <79a5a519-283f-4b25-99e6-778a49046...@m45g2000hsb.googlegroups..com>, b...@signedness.org writes:
    >
    >
    >
    > > Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha,
    > > Intel-64 and even i386 with some hacks to get around hardware
    > > limitations.

    >
    > * *Are you claiming the UNIX kernel examines every instruction to see
    > * *if it was read from data space? *Just separating and marking the
    > * *code read-only doesn't prevent executing writeable data space.
    >


    No thats not what I said. I said most modern ones running on "modern"
    platforms with poor hardware support (no NX bit) do implement work
    arounds.. I did not say a word on how they implement that.. Funny you
    accuse me of not listning.. Anyway if you are interested I believe
    some openbsd developer have done a write up on it, if you can't find
    it there is always the source if you want to know how it works..

    If you prefer a simple test, I have written one for you..

    #include
    #include
    #include

    int f();

    int main()
    {
    char payload[16];
    int (*f)();
    int x;

    strcpy(payload,"\x31\xc0\xb0\x2a\xc3");
    f=(void *)&payload;
    x=f();

    printf("%d\n",f());
    return 0xbadc0ded;
    }




    For those of you not fluent in x86 opcodes, what goes into "payload"
    is simply this:

    xor eax,eax
    mov al,42
    ret

    The calling standard says eax is the register a function returns its
    return value in... Payload is located on the stack (more on that
    later) so if we got an executable stack it will print 42 otherwise it
    will crash.

    So lets test it on FreeBSD which does not support this particular
    feature by default

    $ uname -a
    FreeBSD denial 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52
    UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
    i386
    $ cc stack_test.c -Wall
    $ ./a.out
    42

    OK cool... it works, code execution on the stack like expected....

    Same thing on NetBSD which happens to have a non executable stack on
    i386 by default

    $ uname -a
    NetBSD 4.0 NetBSD 4.0 (GENERIC) #0: Sun Dec 16 00:20:10 PST 2007
    builds@wb34:/home/builds/ab/netbsd-4-0-RELEASE/i386/200712160005Z-obj/
    home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/i386/compile/GENERIC
    i386
    $ cc stack_test.c -Wall -g
    $ ./a.out
    [1] Segmentation fault (core dumped) ./a.out


    Maybe you think it crashed for some other reason? Ok... lets find out

    $ gdb -q a.out
    (gdb) run a.out
    Starting program: /home/christer/a.out a.out

    Program received signal SIGSEGV, Segmentation fault.
    0x08048705 in main () at stack_test.c:16
    16 x=f();
    (gdb) p f
    $1 = (int (*)()) 0xbfbfeccc
    (gdb) info reg esp
    esp 0xbfbfecc0 0xbfbfecc0
    (gdb) x/5bx 0xbfbfeccc
    0xbfbfeccc: 0x31 0xc0 0xb0 0x2a 0xc3


    It crashed on the function call trying to execute stack memory...
    Look at the function pointer and compare it to the stack pointer it is
    actually on the stack... and finally lets just make sure we copied the
    right data into our stack function and that didn't **** up somehow..
    Well what do you know, it was actually the non-executable protection
    that caught it!!! On i386!





    > * *It's been a long time since I saw an OS with both a user interface
    > * *and default writeable code pages during execution. *It was from M$.


    Unless you are talking about versions earlier than win95 I'd like you
    to show me writable code pages on windows by default..

  17. Re: Loose Cannon-dian

    On Sep 15, 10:09*pm, koeh...@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:
    > In article <79a5a519-283f-4b25-99e6-778a49046...@m45g2000hsb.googlegroups..com>, b...@signedness.org writes:
    >
    >
    >
    > > The 3 of us have been doing this for about 10 years (looking for
    > > bugs), and we attend a lot of conferences around the world for people
    > > like us every year. So we know a fair amount of people in our
    > > "industry" and so far only one have said that at some point in time he
    > > thought about having a look at OpenVMS security (but he didn't). Out
    > > of the entire lot we know in the industry we can't name one who have
    > > actually looked at it... People were looking at in the 80s, we know
    > > this, we read the old hacking zines at textfiles.com... But.....

    >
    > * *So, you're behind the times, trying to catch jup, and making broad
    > * *claims about the state of security in an OS you're still learning?


    I think you deliberately are trying to misunderstand me. What I was
    trying to say was that VMS is behind the times because nobody have
    done any serious bug hunting on it since the 80s, which results in bug
    classes that are virtually extinct in other environments were found in
    a matter of hours by someone with absolutely no prior experience with
    VMS.

    >
    > * *That's not a lot of credibility where I come from.
    >


    Ok, how about the fact that we each have about 10 years of experience
    looking for security bugs in MANY MANY different operating systems and
    applications? Does that give us any credibility? Or make us at least a
    tiny bit qualified to talk about what type of bug classes you don't
    ever see in well tested, high quality software anymore? Probably not
    as long as we don't tell you what you want to hear, right?

    >
    >
    > > There are new vulnerability classes and exploitation techniques being
    > > published all the time... Think Moore's law here.. and you'll get an
    > > idea how fast it evolves. I'm sure the people trying to break VMS
    > > security in the 80s were really good for their time, they did not
    > > however have the benefit of 20 years of published research we had
    > > since that. Take the format string bugs in finger, the technique to
    > > expoits those bugs were only made public around 2001. Maybe I would
    > > have agreed that VMS was cool from a security point of view 10-20
    > > years ago, but today compared to the competition? I don't think so.

    >
    > * *20 years of published research on how to hack into poorly designed
    > * *and/or implemented systems may not apply to a system mostly ignored
    > * *by those researchers.
    >


    Why don't you read what I said, I even gave you an example... let me
    break it down for you..

    1) One of the finger bugs we found is a format string vulnerability
    2) The exploitability (or at least the technique that makes this bug
    exploitable) was not publically known until around 2001
    3) That is where the 20 years of published research comes in... The
    people looking at VMS security in the 80s didn't know format string
    bugs were exploitable


    > > Well nothing is impossible I guess. But when actual rocket scientists
    > > (NASA, ESA, whatever the russians call themselves) *keep getting
    > > things like unit conversions wrong and it gets past what I would
    > > assume is fairly rigours QA (at least one would hope so considering
    > > the costs of blowing these things up...) I think you are going to have
    > > to wait a long time before your average programmer create quality
    > > softare without security bugs in something as complex as an operating
    > > system.

    >
    > * *I'm not about to accuse VMS Engineering of being "average
    > * *programmers". *OS complexity is often a result of poor design. *What
    > * *I can see is that UNIX and Windows security design makes it easy
    > * *to screw up. *VMS security design makes it easy to get things right
    > * *(more about that below). *And lots of stiudies have shown that
    > * *rigorous QA actaully can become an excuse for poor work. *("QA will
    > * *catch it if it's wrong." *"It must be good enough, QA passed it.")
    >


    I don't know where you seen those studies, I certainly never read them
    and I have done QA for a large company in the security industry.

    > * *Sure, you can get things right in UNIX and you can screw up in VMS,
    > * *but you don't get a feel for impact of design decisions all that
    > * *fast.


    In all fairness I don't think we talked about design decisions much
    yet.. I believe 99% what we talked about so far has been
    implementation bugs (exploitable code) and the fact it has not been
    tested much by "hackers". We could talk about design too but it would
    be a very long discussion.... And believe me there are lots of things
    I don't like in the UNIX design too. Like I said before I'm not
    religous about my operating systems (even run lots of windows boxes -
    laugh if you want, but it is actually not that bad)

    >
    > * *SUID, SGID, and all or nothing privileges have been tripped over so
    > * *many times as to make thier inherint difficulties obvious. *VMS
    > * *didn't have the equivalent of SUID or SGID for a long, long, time,
    > * *and implemented it in a way that made it easy to use, optional
    > * *to turn on, and completely unjustified to use it like SUID 0. *A
    > * *lot of modern UNIX now have finer grains of privilege, like VMS has
    > * *always had, but when you use a file's mode to SUID 0, what good did
    > * *that granularity do you?


    There is no denying early UNIX ****ed a lot of things up. Even with
    just the user/group and suid/sgid model they could have made things
    much much better. But you know what? The difference is that they have
    admitted to their mistakes and are doing things to fix them and there
    are still a lot of things for them to do, but they have done than VMS
    in recent years.

    It is funny you should mention SUID 0.. Yes great care must be taken
    when you give a "user controlled" process euid 0.. But you have the
    same problem with VMS don't you? Only there the privs are called
    BYPASS, SETPRV, CMKRL, SYSPRV etc but essentially those and a few more
    mean the same thing as uid/euid 0 - complete control over the system.
    Even HP acknowledges this although I can't find the link right now.

    If you want to be in denial about security flaws in VMS that is your
    choice, and you'll be glad to hear we don't have any more conferences
    planned so we don't have to update our slides and are unlikely to look
    for more bugs in VMS unless a client asks us.

    > * *These are just some of the reasons that people who did look for
    > * *vulnerabilities didn't find many, and soon chose easier targets.


    Even if that was true (that they didn't find many in the 80s) I
    already explained that new type of attacks and techniques are found
    all the time and evolve really fast. So the fact that people looking
    for vulns in the 80s didn't find much doesn't mean there were not many
    bugs. And some of the bugs that people missed (or maybe simply didn't
    report) in the 80s we found in a couple of hours and as everybody in
    this group pointed out more than a few time we don't even know the
    operating system!

    I would like to say the reason why we found 3 exploitable local
    vulnerabilities and two remotely exploitable vulnerabilities that
    quickly is because of our super-human bug hunting skills but I'd be
    lying.. The simple truth is that nobody had looked for exploitable
    bugs in VMS for a very long time so there was/is a lot of "low hanging
    fruit".



    > * *I could go on, but you're not listening.



  18. Re: Loose Cannon-dian

    Bob Koehler schrieb:

    >
    > The problem is the asumption behind your question. Just because
    > VMS is more secure than UNIX


    an unproven assumption ...

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


    with the same logic we could abolish exams for students.
    They just would have to show how many text books they own
    in their shelf and that would be enough to graduate.

    And my question is still unanswered,
    which certified security level does VMS reach to put it
    ahead of Unix ?



  19. Re: Loose Cannon-dian

    In article <3e9d55bc-97d2-4d2f-8aa1-efc55f7a84a7@a70g2000hsh.googlegroups.com>, johnwallace4@yahoo.co.uk writes:
    >
    > In respect of your later post: re who's been looking at VMS security
    > and when: did you know that the VMS listings were widely available
    > (for free, iirc) inside DEC, and were available for a relatively small
    > fee to customers (systems houses, etc) outside DEC ? They may still be
    > available, I don't know.


    Prior to about VMS 4.0, listings on microfiche shipped with the
    binaries. So it was awfully hard to install VMS on a VAX without
    also having access to the listings.

    They are currently available for a reasonable price to customers
    who have justification.


  20. Re: Loose Cannon-dian

    In article <00A7FACE.27383E58@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) writes:
    >
    > I think you're making good points, but this is basically an argument you
    > can't win. Their position is that they didn't know much about the system,
    > didn't try very hard, and found some vulnerabilities, at least one of which
    > has now resulted in a MUP to fix a 20+ year old problem. At this point
    > we're better off saying "thank you, and keep up the good work" than in
    > arguing from first principles about how the better engineering and the
    > internal code review and the good design means that there are fewer
    > vulnerabilities than in other systems which have been bashed on harder
    > than VMS has during, oh, the entire lifetime of the commercial internet.


    I have no problem with what they've done, and I do thank them for
    their work. It's the "quality is impossible" attitude they're
    conveying that I have a problem with.


+ Reply to Thread
Page 34 of 35 FirstFirst ... 24 32 33 34 35 LastLast