DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; On Aug 18, 6:55 pm, johnwalla...@yahoo.co.uk wrote: > On Aug 18, 5:00 am, b...@signedness.org wrote: > > > > > On Aug 18, 5:36 am, "Ken Robinson" wrote: > > > > This has been a very interesting and informative ...

+ Reply to Thread
Page 13 of 35 FirstFirst ... 3 11 12 13 14 15 23 ... LastLast
Results 241 to 260 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: VMware codec == VNC codec????

    On Aug 18, 6:55 pm, johnwalla...@yahoo.co.uk wrote:
    > On Aug 18, 5:00 am, b...@signedness.org wrote:
    >
    >
    >
    > > On Aug 18, 5:36 am, "Ken Robinson" wrote:

    >
    > > > This has been a very interesting and informative (for the most part)
    > > > thread. I believe that "bugs" has performed a very good service for
    > > > VMS and should be thanked, not shouted down. I also think that he (and
    > > > his organization) should be invited to the next OpenVMS Technical Boot
    > > > Camp (assuming there is one) next May so he can talk directly to the
    > > > VMS Engineers and Product managers. He should also be allowed to give
    > > > a presentation on how to find these vulnerabilities. I would certainly
    > > > go to a sessions like that.

    >
    > > Thanks a lot for your support!
    > > We will be more than happy to help out in any way that we can.

    >
    > > > BTW, I couldn't see the videos even on a VMware server running CentOS
    > > > 5.1. Also, downloading the necessary codec to my Windows XP laptop
    > > > didn't help.

    >
    > > Hmmz, we should probably look into converting these videos to a more
    > > portable format.
    > > I can not understand why VMWare uses some private codec.

    >
    > > > Ken Robinson

    >
    > "> I can not understand why VMWare uses some private codec."
    >
    > Don't VMware internally use VNC technologies for their displays? And
    > their (lossless) codec simply encodes/decodes those (VNC) graphics
    > updates into a carry-around storage-type format rather than a VMware-
    > internal (er sorry, VNC-native) format?
    >
    > http://www.vmware.com/support/kb/end...are_server.htm
    >

    You are probably correct. It is however sad that they use a format
    that does not work easily on most systems.
    We recorded in VMWare Workstation 6 btw.

    > And speaking of code review (as people rightly were, not too long ago
    > in this thread), some readers may not be aware that VMware themselves
    > recently suffered a bit of an embarrassment which probably ought to
    > have been spotted by decent code review before it stopped people's
    > VMware systems working on August 12th. Something to bear in mind next
    > time the VMware evangelists explain how they're going to solve all the
    > world's consolidation problems by *increasing* the quantity of PC-
    > class software and PC-class processes in the enterprise, rather than
    > by reducing the quantity. Mind you, any non-trivial software has
    > hiccups occasionally, doesn't it? But that's another topic for another
    > day in another place.

    That sounds really interesting, we have missed that.
    We will be more than happy if you can point us to information about
    that.

  2. Re: DEFCON 16 and Hacking OpenVMS

    bugs@signedness.org wrote:

    > WE said nothing about DCL.. Our terminology misleading? Funny..


    A lot of people here were initially under the impression that you were
    talking about DCL. I think it was Sampsa L who came in and added that
    this was for utilities that had command recall, not for DCL.

    If you had started with "utilities that used command recall", there
    would have been no confusion.




    > because it is a security issue, it was presented at a security
    > conference, everyone there seemed to get it, and other people in this
    > group got it too...


    Since probably less than 0.000001% of the people at your security
    convention knew VMS, they would understand the concepts because they
    spoke your langage, but wouldn't understand what goes on under the hood
    because they wouldn't understand VMS.

    The lesson for you is that when you barge in a new community, you cannot
    assume that they will speak your language, especially for an OS you are
    not overly familiar about. And IBM mainframe guy coming here and talking
    about DASD would get blank stares. We use "disk drives" here.

    Now we know what your use of "shellcode" means. But it took a while to
    get it cleared up.

    It wasn't just "shellcode" that confused people here, it was a
    collection of things, such as your irrelevant FILE.EXE discussion, the
    finger stuff, mention of CLI (when in fact it wasn't CLU, it was SMG
    with command recall) which made it very hard for many to see the big
    picture which would have been explained very simply from the get go:

    Within utilities that support command recall, entering a 511 byte
    command, followed by 3 up arrows, followed by 4 bytes will cause that
    utillity to branch to the address specified by those 4 bytes.

    This would have provided a clear, concise and easily understood issue.

    You could have then proceeded to explain how to tested this with your
    code stored in a logical name (known memory location you could branch
    to), and that code calling SYS$CREPRC to create a subprocess that
    inherited the privileges of the installed utility.

    There were *many* here who were confused by your terminology. So perhaps
    you should reviuew your assumption that everyone in the IT industry
    knows your DEFCON terminology.


    > If you don't understand what shellcode means,


    To many, we interpreted "shellcode" as code that runs in a shell. AKA:
    DCL commands in a VMS command procedure , Unix commands in a unix
    script, DOS commands in a .BAT file etc. This provided great amount of
    confusion to your explanations.

    You assumed that everyone n the IT business would have the same
    interpretation of the term "shellcode". This assumption was proven wrong
    in this newsgroup. Perhaps we are an isolated bunch, perhaps your
    "shellcode" definition isn't as widely known as you think it is. I don't
    know. But next time, you jump into a newsgroup of an unfamiliar OS, keep
    this in mind.

  3. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS** 8.3 Patch available **)

    johnwallace4@yahoo.co.uk wrote:

    > VMS these days may be obscure vs its heyday, but traditionally VMS
    > *is* also relatively secure, especially when managed properly (default
    > passwords and similar daftness taken as read). Things like
    > descriptors, STR$ and $FAO and their friends when used properly make
    > it harder for programs to do daft things



    Existance of descriptors is neat, but it didn't prevent this particular
    buffer overflow.

    Existance of ACME routines for intrusion signaling/detection is neat,
    but if POP, IMAP and others doN't use them, it allows hackers to use
    brute force to guess passwords and go undetected.

    VMS *used* to be secure. But software that was added in the last decade
    tends to not use those security measures and makes VMS no so secure anymore.

    Anyone remember the POP server problem when you could manually start the
    POP server interfactively and specify a log filename and the image,
    being privileged, would create that log wherever you specified it , even
    though you didn't have access to that directory/file ?

  4. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS** 8.3 Patch available **)

    Tom Linden schrieb:

    > In your code you would include following which is inherited by all
    > contained
    > scopes to which you would jump (pushing a new stack frame) upon the
    > condition
    > being signaled.
    > ...
    > ON SUBSCRIPTRANGE BEGIN;
    >
    > END;


    >
    > etc.
    > descriptors, or dope vectors are used by the compiler, the programmer
    > doesn't
    > have to explicitly use them, making coding a bit more streamlined.


    My memory may be a bit rusty, but AFAIR the *RANGE conditions
    are usually disabled in production code.
    Moreover, descriptors can be trashed as well since they are passed
    by reference, as are all parameters in PL/I.


  5. Re: DEFCON 16 and Hacking OpenVMS *** V4.7 is fine ***

    On Sun, 17 Aug 2008 20:03:51 -0700 (PDT), FrankS wrote:

    > >The bug has probably been in the
    > > code longer than DEFCONs have been around.

    >
    > I just reproduced the problem on VMS v6.2 (VAX).
    >
    > Anybody got a v5.5-2 or earlier running?


    VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug. This is the
    actual image identification information for SMGSHR.EXE found in V5.5-2:

    image name: "SMGSHR"
    image file identification: "V05-003"
    link date/time: 8-JUL-1992 00:50:52.33
    linker identification: "05-13"

    Instead, the all mighty VAX/VMS V4.7 has NO bug! This is the actual image
    indentification information for SMGSHR.EXE found in V4.7:

    image name: "SMGSHR"
    image file identification: "V04-006"
    link date/time: 22-MAY-1987 23:19:57.76
    linker identification: "04-00"

    This has been patched with security update V2.0 and V3.0, but none of them
    ever modified the SMGSHR.EXE originally shipped with V4.7.

    Proof:

    ATHENA::RPT$ set host florry

    Username: SYSTEM
    Password:
    Welcome to VAX/VMS version V4.7 on node FLORRY
    Last interactive login on Monday, 18-AUG-2008 22:35

    $ sho sys
    VAX/VMS V4.7 on node FLORRY 18-AUG-2008 22:48:30.85 Uptime 0 00:35:24
    Pid Process Name State Pri I/O CPU Page flts Ph.Mem
    00000100 NULL COM 0 0 0 00:35:03.80 0 0
    00000101 SWAPPER HIB 16 0 0 00:00:00.05 0 0
    (...)

    $ set term/dev=unknown
    $ sho term
    Terminal: _RTA2: Device_Type: Unknown Owner: _RTA2:
    (...)

    $ mail

    MAIL> 12345678901234567890123456789012345678901234567890 123456789012(...)
    5678901234567890123456789012345678901(up, up, up, @@@@)

    It stops here. No error message and no ACCVIO, nothing. And it doesn't appear
    to be on loop as per the following CTRL/T output:

    FLORRY::_RTA2: 22:51:31 MAIL CPU=00:00:05.05 PF=2887 IO=2113 MEM=421
    FLORRY::_RTA2: 22:51:32 MAIL CPU=00:00:05.05 PF=2887 IO=2114 MEM=421
    FLORRY::_RTA2: 22:51:36 MAIL CPU=00:00:05.05 PF=2887 IO=2115 MEM=421
    FLORRY::_RTA2: 22:52:06 MAIL CPU=00:00:05.05 PF=2887 IO=2116 MEM=421
    FLORRY::_RTA2: 22:57:03 MAIL CPU=00:00:05.05 PF=2887 IO=2117 MEM=421

    Obviously MAIL.EXE uses SMGSHR.EXE, I've checked it:

    $ ana/ima sys$system:mail.exe /out=ana_mail.tmp
    %ANALYZE-I-ERRORS, SYS$SYSROOT:[SYSEXE]MAIL.EXE;1 0 errors
    $ search ana_mail.tmp smgshr
    global section name: "SMGSHR_001"
    2) "SMGSHR"
    $

    Maybe the bug comes from V5.x "improvements"?

    Bye,
    G.


    --
    Italian Hobbyist DECnet Network - http://decnet.ipv7.net

  6. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS ** 8.3 Patch available **)

    On Mon, 18 Aug 2008 14:22:22 -0700, Michael Kraemer
    wrote:

    > Tom Linden schrieb:
    >
    >> In your code you would include following which is inherited by all
    >> contained
    >> scopes to which you would jump (pushing a new stack frame) upon the
    >> condition
    >> being signaled.
    >> ...
    >> ON SUBSCRIPTRANGE BEGIN;
    >>
    >> END;

    >
    >> etc.
    >> descriptors, or dope vectors are used by the compiler, the programmer
    >> doesn't
    >> have to explicitly use them, making coding a bit more streamlined.

    >
    > My memory may be a bit rusty, but AFAIR the *RANGE conditions
    > are usually disabled in production code.
    > Moreover, descriptors can be trashed as well since they are passed
    > by reference, as are all parameters in PL/I.
    >

    I have always kept them in production code, I try to write failsafe code,
    don't always succeed, but that is the goal. Don't use descriptors, pass
    by value if you are concerned about refrence (By value in PL/I means that
    a copy of the object is made in local store and a pointer to that is
    passed)


    --
    PL/I for OpenVMS
    www.kednos.com

  7. Re: DEFCON 16 and Hacking OpenVMS

    OK, the presentation slides are at:



    Follow up there or here...

  8. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS** 8.3 Patch available **)

    Tom Linden schrieb:

    > I have always kept them in production code, I try to write failsafe code,
    > don't always succeed, but that is the goal. Don't use descriptors, pass
    > by value if you are concerned about refrence (By value in PL/I means that
    > a copy of the object is made in local store and a pointer to that is
    > passed)


    Of course one *can* do all that,
    but it depends on the good will of the programmer
    (just as avoiding buffer overflows in other languages).
    It is not inherent to the language.


  9. Re: VMware codec == VNC codec????

    On Aug 18, 10:02 pm, b...@signedness.org wrote:
    > On Aug 18, 6:55 pm, johnwalla...@yahoo.co.uk wrote:
    >
    > > On Aug 18, 5:00 am, b...@signedness.org wrote:

    >
    > > > On Aug 18, 5:36 am, "Ken Robinson" wrote:

    >
    > > > > This has been a very interesting and informative (for the most part)
    > > > > thread. I believe that "bugs" has performed a very good service for
    > > > > VMS and should be thanked, not shouted down. I also think that he (and
    > > > > his organization) should be invited to the next OpenVMS Technical Boot
    > > > > Camp (assuming there is one) next May so he can talk directly to the
    > > > > VMS Engineers and Product managers. He should also be allowed to give
    > > > > a presentation on how to find these vulnerabilities. I would certainly
    > > > > go to a sessions like that.

    >
    > > > Thanks a lot for your support!
    > > > We will be more than happy to help out in any way that we can.

    >
    > > > > BTW, I couldn't see the videos even on a VMware server running CentOS
    > > > > 5.1. Also, downloading the necessary codec to my Windows XP laptop
    > > > > didn't help.

    >
    > > > Hmmz, we should probably look into converting these videos to a more
    > > > portable format.
    > > > I can not understand why VMWare uses some private codec.

    >
    > > > > Ken Robinson

    >
    > > "> I can not understand why VMWare uses some private codec."

    >
    > > Don't VMware internally use VNC technologies for their displays? And
    > > their (lossless) codec simply encodes/decodes those (VNC) graphics
    > > updates into a carry-around storage-type format rather than a VMware-
    > > internal (er sorry, VNC-native) format?

    >
    > >http://www.vmware.com/support/kb/end...faqid=1246http...

    >
    > You are probably correct. It is however sad that they use a format
    > that does not work easily on most systems.
    > We recorded in VMWare Workstation 6 btw.
    >
    > > And speaking of code review (as people rightly were, not too long ago
    > > in this thread), some readers may not be aware that VMware themselves
    > > recently suffered a bit of an embarrassment which probably ought to
    > > have been spotted by decent code review before it stopped people's
    > > VMware systems working on August 12th. Something to bear in mind next
    > > time the VMware evangelists explain how they're going to solve all the
    > > world's consolidation problems by *increasing* the quantity of PC-
    > > class software and PC-class processes in the enterprise, rather than
    > > by reducing the quantity. Mind you, any non-trivial software has
    > > hiccups occasionally, doesn't it? But that's another topic for another
    > > day in another place.

    >
    > That sounds really interesting, we have missed that.
    > We will be more than happy if you can point us to information about
    > that.


    http://kb2.vmware.com/kb/1006721.html
    http://www.theregister.co.uk/2008/08...st_esx_****up/
    http://blogs.zdnet.com/security/?p=1694
    and doubtless many others.

    I happened across it by chance while doing some RT Linux stuff which
    broke in a VM, so went off to the VMware knowledge base for research,
    found the KB dog slow then offline altogether, then saw some of these
    headlines.

    Somebody at ZDnet classes it as a "security" issue, and in the "denial
    of service" sense, it surely was/is. All eggs in one basket requires a
    high level of confidence in the basket, whether it be VMware or VMS.
    VMS used to have the attention to detail to provide that level of
    confidence. The "native" bits of VMS hopefully still do, but some of
    the "brought in from outside" bits demanded by "the market" haven't
    really been assimilated into the VMS way of working (eg, as JF points
    out, breakin evasion not implemented in some IP stuff).

    Have a lot of fun,
    John

  10. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS** 8.3 Patch available **)

    On Aug 18, 7:59*pm, "Tom Linden" wrote:
    > On Mon, 18 Aug 2008 09:20:19 -0700, wrote:
    > > On Aug 18, 4:23*pm, "Tom Linden" wrote:
    > >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden *
    > >> wrote:
    > >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert *
    > >> > wrote:

    >
    > >> >> b...@signedness.org wrote:
    > >> >>> On Aug 18, 12:09 pm, "Richard Maher"
    > >> >>> wrote:
    > >> >>>> Hi Heine,

    >
    > >> >>>> Well done!

    >
    > >> >>>> Regards Richard Maher

    >
    > >> >>>> PS. Not that it is important, but what I am sceptical about is how *
    > >> *
    > >> >>>> "bugs"
    > >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can someone *
    > >> *
    > >> >>>> post the
    > >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege *
    > >> >>>> vulnerability
    > >> >>>> that occurs everyday in Windows/*nix yet no-one has found on VMS *
    > >> >>>> before,
    > >> >>>> without the help of a few days "generic" hacking, or perhaps the *
    > >> help *
    > >> >>>> of a
    > >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, *
    > >> wave a
    > >> >>>> dead-chicken over your head and howl at the moon - standard stuff*
    > >> for
    > >> >>>> hackers?)

    >
    > >> >>> *No disgruntled deap-throat, no dead chickens or magic wands... The
    > >> >>> simple truth is very few people have bothered looking at VMS because
    > >> >>> it is "secure". If nobody is looking for bugs then no bugs are *
    > >> found.
    > >> >>> How many times have we heard "many eyes makes all bugs shallow"? *
    > >> Well
    > >> >>> still we see really dumb bugs popping up in some of the most popular
    > >> >>> open source applications so it is really that surprising that simple
    > >> >>> bugs are found in an operating system that I would assume very few
    > >> >>> have looked for bugs in since the 80s? (that being said, still a *
    > >> nice
    > >> >>> find by cmn )
    > >> >>> *The finger client bugs are good examples, more or less anyone would
    > >> >>> have found them if they bothered looking for security bugs. The
    > >> >>> seriousness of format string vulnerabilities has been widely known*
    > >> for
    > >> >>> almost 10 years and still there it is (of course it was probably +15
    > >> >>> years since anybody had a serious go at owning VMS).. Speaking of 20
    > >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone *
    > >> remember
    > >> >>> Morris worm? Almost exactly 20 year old bug...

    >
    > >> >> Hell, yes! *There may be some newbies around who haven't heard ofit *
    > >> *
    > >> >> but I was there while it was happening. *Fortunately, I was *
    > >> responsible *
    > >> >> only for some VMS systems which were not affected. *Most of the Unix *
    > >> *
    > >> >> systems in the world were affected. *For those newbies who missed*
    > >> it, *
    > >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg", that*
    > >> >> touches the subject briefly. *I'd say it's a "must read" for anyone *
    > >> >> interested in system security. *It's the only first person account *
    > >> that *
    > >> >> I know of but there may be others.

    >
    > >> >> VMS System Managers are probably aware of a list of forbidden *
    > >> passwords *
    > >> >> maintained by the system. *500 or so of the entries are Robert *
    > >> Morris' *
    > >> >> list of commonly used passwords! *His worm used them to attempt to *
    > >> log *
    > >> >> on to his target systems. *He also abused a buffer overflow *
    > >> >> vulnerability in the finger daemon. *The systems the worm penetrated *
    > >> *
    > >> >> promptly started trying to subvert other systems. . . . *It was an *
    > >> >> interesting two or three days for the Unix system administrators. *
    > >> *VMS
    > >> >> systems were largely unaffected.

    >
    > >> >> Difficult as it may be to believe, hackers are STILL exploiting *
    > >> buffer *
    > >> >> overflows. *There is still a lot of code around that will cheerfully *
    > >> *
    > >> >> attempt to put ten pounds of **** in a five pound bag!

    >
    > >> > Just curious, have you looked at z/os?

    >
    > >> That was meant to be asked of Bugs, got out of sync.

    >
    > >> --
    > >> PL/I for OpenVMSwww.kednos.com

    >
    > > No, nobody asked us to look at it yet. Buying our own system to find
    > > bugs just for the fun of doing it would probably be a bit too
    > > expensive. It would be fun to try, so if someone got a spare machine
    > > let us know....

    >
    > You could run the Hercules emulator, I bet you might even get IBM to loan
    > you a copy of z/os. *The reason I asked was to compare with VMS since the
    > two are often compared in terms of security, the difference is in the
    > implementation in which IBM uses a string safe language, with stringrange
    > checking as an inherenty part of the language, PLS.
    >
    > --
    > PL/I for OpenVMSwww.kednos.com


    Any idea who you would ask at IBM for that?

    I would not be surprised if this language I never heard of had its own
    set of problems with strings though.. Other "safe" languages, maybe
    most notably python and php have had some really bad bugs in their
    interpretors dealing with this if I remember correctly.


  11. RE: DEFCON 16 and Hacking OpenVMS

    > -----Original Message-----
    > From: William Webb [mailto:william.w.webb@gmail.com]
    > Sent: August 18, 2008 4:16 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: DEFCON 16 and Hacking OpenVMS
    >
    > On Mon, Aug 18, 2008 at 1:59 PM, Bill Gunshannon
    > wrote:
    > >
    > > In article

    > > t>,
    > > "Main, Kerry" writes:
    > > >
    > > > I am not trying to pass judgement one way or another. And most in

    > this
    > > > newsgroup would never state that OpenVMS is technically unhackable
    > > > and/or not susceptible to security issues.
    > > >

    > >
    > > Damn Kerry, they have been saying it as long as I have been here!!!
    > >
    > > bill
    > >
    > > --
    > > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three

    > wolves
    > > billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
    > > University of Scranton |
    > > Scranton, Pennsylvania | #include

    >
    >
    > One of my favorite IT Security quotes:
    >
    > "Anybody who says his system is bulletproof is either a liar or
    > stupid."
    >
    > Winn Schwartau
    >
    > WWWebb



    Hey, reminds me of Mission Impossible movie .. remember Tom Cruise
    in a horizontal position being lowered from ceiling to logon to system
    that had no connections outside of room?

    [ok, ok, it was a movie, but one gets the point]

    Fwiw, there no such thing as unhackable when one understands that overall
    security is a function of people, process *and* technology (PPT). Course,
    the better the technology, the better the overall solution.

    :-)

    Regards



  12. Re: DEFCON 16 and Hacking OpenVMS *** V4.7 is fine ***

    On Aug 18, 5:35*pm, gerr...@no.spam.mail.com wrote:
    > VAX/VMS V5.5-2 (with all the ECOs found on ITRC) has the bug.


    Interesting. That's something like 16 years that the bug has been
    around and never been spotted?

    I guess that shows that there aren't many people working on VMS that
    spend their days keying in 511+ characters looking for buffer
    overflows.

    :-)

  13. Re: DEFCON 16 and Hacking OpenVMS

    bugs@signedness.org wrote:
    > On Aug 18, 1:21 pm, VAXman- @SendSpamHere.ORG wrote:
    >
    >>In article , b...@signedness.org writes:
    >>
    >>
    >>
    >>
    >>>On Aug 17, 10:09 pm, VAXman- @SendSpamHere.ORG wrote:

    >>
    >>>>>It was pointed to you that the codecs used in the videos are
    >>>>>non-standard and cannot be watched by everyone. I also didn't even
    >>>>>bother to download them.
    >>>
    >>>It is a VMWare recording for heavens sake (http://www.vmware.com)!
    >>>If you have bothered to download the videos you would probably not
    >>>have
    >>>played around with DCL commands and asked about FILE.EXE in the first
    >>>place.

    >>
    >>>>A cohesive explaination of reproducing the stack dump would have been
    >>>>better than some video of a terminal session. There was also a report
    >>>>of no audio explaining what was happening in the video.
    >>>
    >>>It is a VMWare recording (http://www.vmware.com/), it has no sound.
    >>>We used the videos in our presentation (and yes, we did actually
    >>>talk while playing them).

    >>
    >>>>>Your introduction of FILE.EXE was absolutely confusing. This was not
    >>>>>necessary. And reduced your credibility because it put the focus on the
    >>>>>"file.exe" instead of on the actual vulnerability.

    >>
    >>>>Another valid point.
    >>>
    >>>Again, you did not watch the videos, i.e. you did not input all data
    >>>before computing.

    >>
    >>>You continue to claim that we have done things wrong when trying to
    >>>explain the vulnerability that you tried to wave away as a hoax. Your
    >>>attitude strongly imply that this has nothing to do with terminology
    >>>and codecs, but that your ego got bumped really hard, and you can not
    >>>handle it.

    >>
    >>There's no need for you to be so condescending.
    >>
    >>It's not about ego. I, and others here, were trying to determine if
    >>this truly was a vulnerability. The first reports were that this was
    >>a vulnerability in the DCL CLI easily exploited with a buffer over-
    >>flow. The published instructions to cause the overflow did NOT pro-
    >>duce the results reported. _Your_ terminology was misleading -- not
    >>the 'shellcode' thing either!
    >>
    >>As for your VIDEO... I did, this past weekend, view the one called:
    >>openvms_local_install_exploit.avi.
    >>
    >>1. You telnet into a VMS system.
    >> (this command sting alone is confusing)
    >>2. delete PRIVS.TXT
    >>3. run FILE.EXE
    >>4. type PRIVS.TXT
    >> (privs output)
    >>5. delete PRIVS.TXT
    >>6. then you run LOADCODE leaving a prompt SHELLCODE>>
    >>7. from this point you execute INSTALL... etc., etc., etc.
    >>
    >>To me, it looks like you wrote your own CLI which is being used in
    >>the spawned subprocess. Again, this obfuscates the reality.
    >>
    >>
    >>>There is a bug for you to analyze.

    >>
    >>One the missing bits were properly explained, I was able to produce the
    >>stack dump.
    >>
    >>I've written my OWN 'shellcode' now. I load about 150 bytes of code to
    >>P1 via a supported and documented user invokable mechanism! This code
    >>sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with
    >>SS$_NORMAL. All of this executed in a normal DECwindows terminal.
    >>
    >>NOW, had you, perhaps:
    >>
    >>1. not changed your prompt
    >>2. executed INSTALL from DCL
    >>3. not returned the BADPARAM stack
    >>4. explained, after the long string of AAAs, about the unseen I/O
    >>
    >>there would have been more and immediate credence placed in your claim.
    >>
    >>My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would
    >>have sufficed??? Your claim was something about output capturing. I
    >>fail to see why you can capture normal terminal I/O from a TYPE command
    >>but not from SHOW PROCESS/PRIVILEGES. This is the type of thing that's
    >>caused much of the confusion, doubt and distrust here. I have no issue
    >>invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to
    >>P1. I don't need to SPAWN a sub-process; albeit, for testing, I did to
    >>allow quick cleanup of P1 space with a logout.
    >>
    >>And, for the record, I did not proclaim this to be a hoax. However, in
    >>light of your, and others, instuctions which were muddled, incomplete,
    >>and riddled with misleading jargon, I would expect that the good folks
    >>of comp.os.vms would be dubious.
    >>
    >>FWIW, I have been in contact with a number of people working independ-
    >>ently on patches to thwart this attack. Interim fixes until a patch or
    >>fix is released by HP.
    >>
    >>--
    >>VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
    >>
    >>... pejorative statements of opinion are entitled to constitutional protection
    >>no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >>
    >>Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    >>of usenet _must_ include its contents in its entirety including this copyright
    >>notice, disclaimer and quotations.

    >
    >
    > Well congratulations, now you pissed me off too and not just cmn..
    >
    > WE said nothing about DCL.. Our terminology misleading? Funny..
    > because it is a security issue, it was presented at a security
    > conference, everyone there seemed to get it, and other people in this
    > group got it too... If you don't understand what shellcode means,
    > don't google it, or ask and then make the wrong assumptions that is
    > hardly our ****ing fault now is it?


    This is complete bull****. People here asked *repeatedly* for you to define
    your terms, including the term "shellcode" and you just blew them off.

    This is like a bad tourist using an unfamiliar or misprounced word and
    just shouting it louder when the person they are trying to communicate
    with says "What?"

    >
    >
    > OH AND CONDESCENDING????? GIVE ME A ****ING BREAK! Remember the "1337
    > haxOrz" Comment? What do you call that? Yeah we may not be old enough
    > to remember the dinosaurs or having written code on punch cards...
    > Well guess what, we still found and exploited multiple vulnerabilities
    > in VMS.. even if we are not in the right little click of superior
    > beings such as yourself..
    >
    > Then you say discussing how to "weaponize" this exploit is not a good
    > idea for public discussion.... We seem to recall demands that we
    > release our exploit.... Double standards??? Oh and talking about your
    > shellcode is ok? oh wait... it can't be that you still are trying to
    > prove that you are superior to us for using a different method, can
    > it?
    >
    > Or as another poster so elegantly put it:-
    >
    > "It's amazing how many people can *now* get the egg to stand on its
    > end once they've been shown how :-( Oh, but your egg stands so much
    > prouder."
    >
    >




    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  14. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS ** 8.3 Patch available **)

    On Mon, 18 Aug 2008 15:25:48 -0700, Michael Kraemer
    wrote:

    > Tom Linden schrieb:
    >
    >> I have always kept them in production code, I try to write failsafe
    >> code,
    >> don't always succeed, but that is the goal. Don't use descriptors,
    >> pass
    >> by value if you are concerned about refrence (By value in PL/I means
    >> that
    >> a copy of the object is made in local store and a pointer to that is
    >> passed)

    >
    > Of course one *can* do all that,
    > but it depends on the good will of the programmer
    > (just as avoiding buffer overflows in other languages).
    > It is not inherent to the language.
    >

    Well, in a way it is the language. Of course, you can write safe code in
    most langugaes, but soem make it easier to not do so. And since most people
    are lazy, particularly since it more arduous in languages like C.





    --
    PL/I for OpenVMS
    www.kednos.com

  15. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS ** 8.3 Patch available **)

    On Mon, 18 Aug 2008 15:42:21 -0700, wrote:

    > On Aug 18, 7:59*pm, "Tom Linden" wrote:
    >> On Mon, 18 Aug 2008 09:20:19 -0700, wrote:
    >> > On Aug 18, 4:23*pm, "Tom Linden" wrote:
    >> >> On Mon, 18 Aug 2008 07:24:14 -0700, Tom Linden

    >> *
    >> >> wrote:
    >> >> > On Mon, 18 Aug 2008 07:09:11 -0700, Richard B. Gilbert *
    >> >> > wrote:

    >>
    >> >> >> b...@signedness.org wrote:
    >> >> >>> On Aug 18, 12:09 pm, "Richard Maher"

    >>
    >> >> >>> wrote:
    >> >> >>>> Hi Heine,

    >>
    >> >> >>>> Well done!

    >>
    >> >> >>>> Regards Richard Maher

    >>
    >> >> >>>> PS. Not that it is important, but what I am sceptical about is

    >> how *
    >> >> *
    >> >> >>>> "bugs"
    >> >> >>>> found/stumbled-across/zeroed-in on this vulnerability! Can

    >> someone *
    >> >> *
    >> >> >>>> post the
    >> >> >>>> analogous equivalent on *nix? I mean a 20 year-old privilege *
    >> >> >>>> vulnerability
    >> >> >>>> that occurs everyday in Windows/*nix yet no-one has found on

    >> VMS *
    >> >> >>>> before,
    >> >> >>>> without the help of a few days "generic" hacking, or perhaps

    >> the *
    >> >> help *
    >> >> >>>> of a
    >> >> >>>> disgruntled deap-throat? Amazing! (511 bytes, uparrow 3 times, *
    >> >> wave a
    >> >> >>>> dead-chicken over your head and howl at the moon - standard

    >> stuff *
    >> >> for
    >> >> >>>> hackers?)

    >>
    >> >> >>> *No disgruntled deap-throat, no dead chickens or magic wands...

    >> The
    >> >> >>> simple truth is very few people have bothered looking at VMS

    >> because
    >> >> >>> it is "secure". If nobody is looking for bugs then no bugs are *
    >> >> found.
    >> >> >>> How many times have we heard "many eyes makes all bugs shallow"?

    >> *
    >> >> Well
    >> >> >>> still we see really dumb bugs popping up in some of the most

    >> popular
    >> >> >>> open source applications so it is really that surprising that

    >> simple
    >> >> >>> bugs are found in an operating system that I would assume very

    >> few
    >> >> >>> have looked for bugs in since the 80s? (that being said, still a

    >> *
    >> >> nice
    >> >> >>> find by cmn )
    >> >> >>> *The finger client bugs are good examples, more or less anyone

    >> would
    >> >> >>> have found them if they bothered looking for security bugs. The
    >> >> >>> seriousness of format string vulnerabilities has been widely

    >> known *
    >> >> for
    >> >> >>> almost 10 years and still there it is (of course it was probably

    >> +15
    >> >> >>> years since anybody had a serious go at owning VMS).. Speaking

    >> of 20
    >> >> >>> year old vulns, what about Shaun Colley's fingerd bug? Anyone *
    >> >> remember
    >> >> >>> Morris worm? Almost exactly 20 year old bug...

    >>
    >> >> >> Hell, yes! *There may be some newbies around who haven't heard of

    >> it *
    >> >> *
    >> >> >> but I was there while it was happening. *Fortunately, I was *
    >> >> responsible *
    >> >> >> only for some VMS systems which were not affected. *Most of the

    >> Unix *
    >> >> *
    >> >> >> systems in the world were affected. *For those newbies who missed

    >> *
    >> >> it, *
    >> >> >> Clifford Stoll wrote a very readable book, "The Cuckoo's Egg",

    >> that *
    >> >> >> touches the subject briefly. *I'd say it's a "must read" for

    >> anyone *
    >> >> >> interested in system security. *It's the only first person

    >> account *
    >> >> that *
    >> >> >> I know of but there may be others.

    >>
    >> >> >> VMS System Managers are probably aware of a list of forbidden *
    >> >> passwords *
    >> >> >> maintained by the system. *500 or so of the entries are Robert *
    >> >> Morris' *
    >> >> >> list of commonly used passwords! *His worm used them to attempt

    >> to *
    >> >> log *
    >> >> >> on to his target systems. *He also abused a buffer overflow *
    >> >> >> vulnerability in the finger daemon. *The systems the worm

    >> penetrated *
    >> >> *
    >> >> >> promptly started trying to subvert other systems. . . . *It was

    >> an *
    >> >> >> interesting two or three days for the Unix system administrators.

    >> *
    >> >> *VMS
    >> >> >> systems were largely unaffected.

    >>
    >> >> >> Difficult as it may be to believe, hackers are STILL exploiting *
    >> >> buffer *
    >> >> >> overflows. *There is still a lot of code around that will

    >> cheerfully *
    >> >> *
    >> >> >> attempt to put ten pounds of **** in a five pound bag!

    >>
    >> >> > Just curious, have you looked at z/os?

    >>
    >> >> That was meant to be asked of Bugs, got out of sync.

    >>
    >> >> --
    >> >> PL/I for OpenVMSwww.kednos.com

    >>
    >> > No, nobody asked us to look at it yet. Buying our own system to find
    >> > bugs just for the fun of doing it would probably be a bit too
    >> > expensive. It would be fun to try, so if someone got a spare machine
    >> > let us know....

    >>
    >> You could run the Hercules emulator, I bet you might even get IBM to
    >> loan
    >> you a copy of z/os. *The reason I asked was to compare with VMS since
    >> the
    >> two are often compared in terms of security, the difference is in the
    >> implementation in which IBM uses a string safe language, with
    >> stringrange
    >> checking as an inherenty part of the language, PLS.
    >>
    >> --
    >> PL/I for OpenVMSwww.kednos.com

    >
    > Any idea who you would ask at IBM for that?


    Had you asked me that 20 years ago I could have given you an answer
    >
    > I would not be surprised if this language I never heard of had its own
    > set of problems with strings though.. Other "safe" languages, maybe
    > most notably python and php have had some really bad bugs in their
    > interpretors dealing with this if I remember correctly.


    I am not claiming tha code written in PL/I is safe, just that it is far
    easier
    to do so. Strings are well treated in the language and null is a perfectly
    valid lexeme with no special significance, strings are either fixed length
    or
    variable with a 2-byte length prefix, checking for a variety conditions is
    wealthy. The reference manual is online at the below site, and you can get
    a hobbyist license for no charge.






    --
    PL/I for OpenVMS
    www.kednos.com

  16. Re: DEFCON 16 and Hacking OpenVMS

    On Mon, 18 Aug 2008 16:49:27 -0700, John Santos wrote:

    > This is like a bad tourist using an unfamiliar or misprounced word and
    > just shouting it louder when the person they are trying to communicate
    > with says "What?"
    >


    Oh, you mean like the bellman in Faulty Towers?


    --
    PL/I for OpenVMS
    www.kednos.com

  17. Re: DEFCON 16 and Hacking OpenVMS

    On Sun, Aug 17, 2008 at 8:17 PM, patrick jankowiak wrote:
    > %%%%%%%%%%%%%Message from Opcom
    >
    > It makes no sense to be pissin' off the hackers over credentials,
    > terminology, and the vernacular. If something has been found that needs
    > attention, and they're decent enough to try to get HP to fix it and in the
    > same sentence don't want to reveal the naughty details publicly until a
    > patch has been released, then what's the beef with them? One does not have
    > to be a car mechanic to put a skunk in the trunk, nor a plumber to hide an
    > opossum in the potty. One just has to figure out a way to do it and then
    > stand back and watch the youtube moment. Ok bad analogies.
    >
    > This whole discussion is extremely interesting and the contributors are too
    > diverse to waste storage and bandwidth making negative comments over the
    > many specific credentials, words, and grammar.
    >


    I concur with Pat.

    Interesting little discoveries indeed, guys. Certainly worthy of
    spirited conversation.

    And if some in comp.os.vms have ticked you off, you haven't seen anything.

    Google one "Carl J. Lydick" for someone who could really flame "back
    in the day."

    And as I said I would do, I've spoken with "people" but haven't gotten
    a response back to date.

    (And even if I had, I certainly wouldn't talk about it in public fora
    without specific permission to do so; this is usually de rigeur for
    security issues.)

    WWWebb

  18. Re: DEFCON 16 and Hacking OpenVMS

    William Webb wrote:

    > And as I said I would do, I've spoken with "people" but haven't gotten
    > a response back to date.



    Has the VMS group been virtualised to a point where you need to use
    quotes around people to denote the fact ther they aren't real anymore ?

  19. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS** 8.3 Patch available **)

    Tom Linden schrieb:

    > Well, in a way it is the language. Of course, you can write safe code in
    > most langugaes, but soem make it easier to not do so. And since most people
    > are lazy, particularly since it more arduous in languages like C.


    If safety features are disabled by default (as it was in PL/I
    as I know it) they are of limited value. PL/I has some merits
    of its own, but increased safety is not among them, IMHO.
    Looking back to my old PL/I days I had as many crashes
    back then as later on with C programs.
    And we haven't discussed yet the mess you can cause
    in both languages with trashed pointers.


  20. Re: When the goin' gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS ** 8.3 Patch available **)

    In article
    <2e2b8a4a-c12d-4c73-b4db-9b2a7036efc6@f36g2000hsa.googlegroups.com>,
    bugs@signedness.org wrote:

    > On Aug 18, 7:59*pm, "Tom Linden" wrote:


    > >
    > > You could run the Hercules emulator, I bet you might even get IBM to loan
    > > you a copy of z/os. *The reason I asked was to compare with VMS since the
    > > two are often compared in terms of security, the difference is in the
    > > implementation in which IBM uses a string safe language, with stringrange
    > > checking as an inherenty part of the language, PLS.
    > >

    >
    > Any idea who you would ask at IBM for that?
    >


    I don't know how to get the IBM software, but the best place to start
    will be the Hercules emulator web site. The folks there will surely know.

    http://www.hercules-390.org/

    > I would not be surprised if this language I never heard of had its own
    > set of problems with strings though.. Other "safe" languages, maybe
    > most notably python and php have had some really bad bugs in their
    > interpretors dealing with this if I remember correctly.


    Why not take a look?

    --
    Paul Sture

+ Reply to Thread
Page 13 of 35 FirstFirst ... 3 11 12 13 14 15 23 ... LastLast