DEFCON 16 and Hacking OpenVMS - VMS

This is a discussion on DEFCON 16 and Hacking OpenVMS - VMS ; In article , "Tom Linden" wrote: > As for terminology, payload is certainly better than shellcode. 'tis worth looking at the Wiki entry here: http://en.wikipedia.org/wiki/Shellcode "Shellcode From Wikipedia, the free encyclopedia In computer security, a shellcode is a small piece ...

+ Reply to Thread
Page 11 of 35 FirstFirst ... 9 10 11 12 13 21 ... LastLast
Results 201 to 220 of 691

Thread: DEFCON 16 and Hacking OpenVMS

  1. Re: DEFCON 16 and Hacking OpenVMS

    In article ,
    "Tom Linden" wrote:

    > As for terminology, payload is certainly better than shellcode.


    'tis worth looking at the Wiki entry here:

    http://en.wikipedia.org/wiki/Shellcode

    "Shellcode
    From Wikipedia, the free encyclopedia

    In computer security, a shellcode is a small piece of code used as the
    payload in the exploitation of a software vulnerability. It is called
    "shellcode" because it typically starts a command shell from which the
    attacker can control the compromised machine. Shellcode is commonly
    written in machine code, but any piece of code that performs a similar
    task can be called shellcode. Because the function of a payload is not
    limited to merely spawning a shell, some have suggested that the name
    shellcode is insufficient.[1] However, attempts at replacing the term
    have not gained wide acceptance."

    The last couple of sentences do indicate that the name shellcode has
    shortcomings. For the sake of completeness, footnote [1] above
    references the following book:

    "Sockets, Shellcode, Porting, & Coding: Reverse Engineering Exploits and
    Tool Coding for Security Professionals. by James C. Foster and Stuart
    McClure (April 12, 2005). ISBN 1-59749-005-9"

    --
    Paul Sture

  2. Re: DEFCON 16 and Hacking OpenVMS

    In article , bugs@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.

  3. Re: DEFCON 16 and Hacking OpenVMS

    In article , JONESD@ecr6.ohio-state.edu (David Jones) writes:
    >In message ,
    > bugs@signedness.org writes:
    >>Btw, any suggestions on how to trigger this automatically without
    >>using a custom telnet/ssh client?

    >
    >So your goal is to create a trojan horse program that secretly breaks in
    >when a non-privileged user runs it?
    >
    >>Using popen() or an input file with lib$spawn does not work (popen()
    >>is probably implemented using lib$spawn), because the input is not a
    >>terminal why the vulnerable code is not used.

    >
    >If SMG doesn't think input is from an interactive terminal, there is no
    >editting so there is no need to try to interpret escape characters.
    >
    >You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
    >process to it. The parent process controlling the terminal doesn't need to
    >supply a password and none of the dialog needs to be displayed. Use the
    >exploit to grant that spawned process privileges and then just use that session
    >to do other things with the empowered process.


    I don't believe that discussing how to "weaponize" this exploit is a good
    idea for public discussion here in c.o.v.

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

  4. Re: DEFCON 16 and Hacking OpenVMS

    In article <48a5dea9$0$1847$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >
    > Since there is no such thing as "shellcode" in VMS, it would greatly
    > help if you use terminology native to VMS so we could understand it.


    Guess again. In the fiche (OK, I'm using my wayback), there is a
    "shell" in VMS. Its part of the code used to map and start the CLI.
    IIRC it isn't DCL specific, it would be the same shell starting DCL,
    MCR, or DECshell.

    But that is not what the OP was discussing. He was using the term
    "shellcode" in a more generic sense, a sense documented on Wiki, as
    he has cited.

    I haven't had time to test these exploits on my 8.3 systems, or my
    finger clients. I am convinced that sufficient evidence has been
    produced that I should expect them to work if I haven't already
    installed the patches, which might be the case on one of my hobbyist
    systems.

    It's not clear to me how the finger exploit reaches arbitrary code,
    but it doesn't look out of the realm of possibility. I'm satisfied
    that the DCL exploit did demonstrate execution of code with elevated
    priviliges.

    Now lets all get to work and patch our systems.

    VMS: 4, UNIX 2.E8, Windows 2.E99, live with it. (No, I'm not going
    to dig up the other 2 VMS exploits I knew about, but be carefull if
    you're still running 1.x on your 11/780.)



  5. Re: DEFCON 16 and Hacking OpenVMS

    In article <48a623a0$0$18525$c3e8da3@news.astraweb.com>, JF Mezei writes:
    > VAXman- @SendSpamHere.ORG wrote:
    >
    >> Memory is readable-only or read-write on Alpha. There's nothing in the
    >> PTE on VMS to indicate that it is or is not executable instruction code.

    >
    > Oh wow. I was way off then. Was this the case for VAX where memory would
    > be tagged as executable or not ?


    On both VAX and Alpha, executable vs. non-executable PSECTS are just
    notes to the linker because programs page more efficiently if you
    keep the executable code together. VAX and Alpha do not enforce
    noexe at runtime.

    Alpha's Macro-32 (and I think Macro-64) does complain if you put code
    in a noexe PSECT, or data in an exe PSECT, but you are at liberty to
    ignore it. It just slows your program down.

    IA-64 does have the ability to enforce noexe at runtime, and VMS does
    make use of it.


  6. That dome in Florence (was::Re: DEFCON 16 and Hacking OpenVMS)

    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.

    Regards Richard Maher

    wrote in message
    news:00A7E493.F1C14444@SendSpamHere.ORG...
    > In article

    ,
    bugs@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.




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

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



    > PPS. I think the "LOTS" claims are premature (and disrespectful given VMS's
    > credentials) even if "bugs" has the runs on the board (and the Aussies are
    > still beating the poms :-) VMS *is* architected to be extremely secure! But
    > as you know, obviously better than me, it's only as secure as it's weakest
    > link (or RTL) or layered product. And thanks to to the "Industry Standard"
    > drones that run the current mess that is VMS middle-management, who knows
    > how deep this canker runs.
    >


    We'll see hopefully more people start looking for bugs.. And not only
    memory corruption bugs, there are quite a few things in documentation
    that should make you think.. For example what about debugging? I read
    privileged images need to be linked with /NODEBUG to be installed, I
    think everybody understands why it is undersirable to let users debug
    a privileged program. But how is this actually implemented? Is
    "limitation" actually enforced by the kernel? Maybe, I have no idea,
    but the way I read it, it could just as well mean that it is enforced
    by INSTALL / DEBUG. And there are many many more little things like
    that someone should look into. Not to mention what would probably be
    found if someone did a proper source audit........


    > PPPS. But ol' Ann industry-standard MacQuaid can still keep the Andy
    > Goldsteins down in the dungeon doing *nix semaphores while this **** is
    > going on? Is there anyone accountable in this den of vipers? Where does the
    > ****ing buck stop?
    >
    > "Hein RMS van den Heuvel" wrote in messagenews:41c28c10-2d7a-49df-b984-2f89dff6f6a9@c65g2000hsa.googlegroups.com...
    > On Aug 16, 11:19 pm, VAXman- *@SendSpamHere.ORG wrote:
    >
    > > >Thanks for that important additional piece of information. I can now
    > > >reproduce it on my Alpha VMS 8.3 home system.

    >
    > > Save that after further investigation, it's not DCL... it's in a shareable
    > > image. The shareable and code has been identified.

    >
    > I believe to have a full patch for this for Open Alpha VMS 8.3.
    > Caveat... this has had but 5 minutes of testing!
    >
    > Patches for other versions should be much similar.
    > This is not just a workaround, like extending the buffer.
    > The patch *limits the max number of characters after an escape to 3
    > (or however many you like... which should be less than the 4 bytes
    > allocated).
    > It replaces a NOP, and some broken code, and with that an idle
    > register, to do its modest job.
    >
    > $ dump/block=(count=1,start=124) sys$library:smgshr.exe;/
    > out=smgshr_original.dmp
    > $ copy/log sys$library:smgshr.exe; smgshr_patched.exe
    > $ patch *smgshr_patched.exe
    > define base=07c*200-200
    > deposit base+044 = 47E07401
    > deposit base+0ac = 40203121
    > deposit base+0b4 = 2FFE0000
    > deposit base+0d8 = 0E4200017
    > update
    > exit
    > $ *dump/block=(count=1,start=124) smgshr_patched.exe; /
    > out=smgshr_patched.dmp
    >
    > This should report:
    >
    > old: 0000F644: *2FFE0000
    > new: 0000F644: *47E07401
    > old: 0000F6AC: *2020FDD4
    > new: 0000F6AC: *40203121
    > old: 0000F6B4: *441F0281
    > new: 0000F6B4: *2FFE0000
    > old: 0000F6D8: *0F4200017
    > new: 0000F6D8: *0E4200017
    >
    > Now try your reproducer, or at least define smgshr to this patch image
    > and make sure it still work, with say MAIL, type/page, or pretty much
    > anything else.
    > When comfident move to SYS$LIBRARY.
    >
    > hth,
    >
    > Hein.



  8. Re: DEFCON 16 and Hacking OpenVMS

    In article , "Tom Linden" writes:
    >
    > How would you go about this on a remote machine to which you do not
    > have login priveleges?


    Both of these exploits are useable only to people who already have
    access, although unprivileged. That's enough to get my attention.


  9. Re: DEFCON 16 and Hacking OpenVMS

    In article , "Tom Linden" writes:
    >
    > Well I have always disabled fingerd whether on Unix or VMS, but there
    > may well be other avenues. Such exploits would not be possible had the
    > code
    > been written using a safe language like PL/I or Ada with apporpriate
    > ON conditions.


    If I understand correctly, the exploit is not through the finger
    server (fingerd), but the finger client. Is your finger client
    disabled?


  10. Re: DEFCON 16 and Hacking OpenVMS

    In article , david20@alpha2.mdx.ac.uk writes:
    >
    > This bug doesn't effect all images with embedded commandline commands for
    > instance SYSGEN seems to have been written to cope with it
    >


    SYSGEN does it's own terminal I/O, it's been around much longer than
    other utilities and the code needs to execute in the limited
    environment provided when stopping during the boot process.


  11. Re: DEFCON 16 and Hacking OpenVMS

    On Aug 18, 2:26 pm, VAXman- @SendSpamHere.ORG wrote:
    > In article , JON...@ecr6.ohio-state.edu (David Jones) writes:
    >
    >
    >
    > >In message ,
    > > b...@signedness.org writes:
    > >>Btw, any suggestions on how to trigger this automatically without
    > >>using a custom telnet/ssh client?

    >
    > >So your goal is to create a trojan horse program that secretly breaks in
    > >when a non-privileged user runs it?

    >
    > >>Using popen() or an input file with lib$spawn does not work (popen()
    > >>is probably implemented using lib$spawn), because the input is not a
    > >>terminal why the vulnerable code is not used.

    >
    > >If SMG doesn't think input is from an interactive terminal, there is no
    > >editting so there is no need to try to interpret escape characters.

    >
    > >You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED
    > >process to it. The parent process controlling the terminal doesn't need to
    > >supply a password and none of the dialog needs to be displayed. Use the
    > >exploit to grant that spawned process privileges and then just use that session
    > >to do other things with the empowered process.

    >
    > I don't believe that discussing how to "weaponize" this exploit is a good
    > idea for public discussion here in c.o.v.


    If it was up to you to decide what should be in this group it would
    only be
    a maximum of two posts in every thread, the first post with a question
    and a second post with a correct answer from you.

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



  12. RE: DEFCON 16 and Hacking OpenVMS

    > -----Original Message-----
    > From: Simon Clubley [mailto:clubley@remove_me.eisner.decus.org-
    > Earth.UFP]
    > Sent: August 18, 2008 7:29 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: RE: DEFCON 16 and Hacking OpenVMS
    >
    > 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.
    > >
    > > Simply that it is much more difficult than most of the other OS's.
    > >

    >
    > On what basis do you make that statement as general as that ?
    >


    No OS is 100% secure. No one here should ever state that. OpenVMS will
    occasionally have security issues identified. It has been discussed here
    many times before, but security arch requires it to be designed as part
    of the base OS - not added on later.

    Overview:
    http://h71028.www7.hp.com/ERC/downlo...A0-2896ENW.pdf

    It's also a question of the volume of security patches. Each platform can be
    made relatively secure with hand tuning and applying patches etc. However,
    with 5-20 new security patches being released every month, how do you
    ensure your platform continues to be secure when you have the challenges
    of having to re-test applications and platforms before new patches are
    rolled out?

    Again, no OS is 100% secure and other issues will potentially be found
    with OpenVMS in the future.

    That does not mean OpenVMS is not a very secure OS. Its history speaks
    for itself. There has been exploits, but very few.

    > For example, RedHat Linux now has SELinux built in, so that even if a
    > service gets compromised, there's the possibility that the attacker
    > will
    > be constrained (at least at operating system level as opposed to
    > application level).
    >


    Red Hat *monthly* security (not maint) issues can be found at:
    https://www.redhat.com/archives/enterprise-watch-list/
    (click on thread for each month and add them up yourself)

    > The SMG exploit discussed here uses the same attack mechanism (buffer
    > overflow/stack trashing) as on other operating systems and once the
    > vulnerability was discovered, VMS security didn't make a difference
    > to been able to exploit a privileged program.
    >
    > I have three related questions for you:
    >
    > 1) The %n UCX finger client issue appears to be a case of the
    > programmer
    > writing something like
    >
    > printf(untrusted_text);
    >
    > instead of the safer
    >
    > printf("%s", untrusted_text);
    >
    > If that's confirmed, then that's a student level programming mistake
    > that
    > should never have been made in the first place, and if it was, then it
    > should have been caught by normal code review processes.
    >
    > If that's confirmed as the cause what do you think about having very
    > poor
    > quality code like that within the UCX code base ? What do you think
    > about
    > the fact that it was missed during code review ?
    >


    It has not been confirmed so why speculate until it has?

    Btw, not to say this is not a potential issue, but as you know, not every
    Cust uses TCPIP Services (Multinet, TCPware etc)

    > As for me, I'm worried about what the programmer who wrote that may
    > have
    > done in the rest of the UCX code base.
    >
    > 2) The DNS issues still haven't had a formal patch released. Although
    > you can go and ask for the patches if you know they exist, they still
    > have not been announced as a formal patch. As you remind us at every
    > opportunity, other vendors announce security patches to their
    > customers.
    >


    Did you not see the announcement at?
    http://h71000.www7.hp.com/network/new.html

    > What do you think about UCX engineering not issuing a formal
    > announcement
    > of a security issue ?
    >
    > 3) The DNS issue was a high profile event. How many other security
    > issues
    > have been discovered within UCX and for which there are patches
    > available,
    > but we don't actually know about because UCX engineering have not
    > bothered
    > to announce the patch ?
    >


    http://h71000.www7.hp.com/network/new.html


    > Simon.
    >
    > --
    > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    > Microsoft: Bringing you 1980's technology to a 21st century world


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

    bugs@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!

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

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

    > bugs@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?

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

  15. Re: DEFCON 16 and Hacking OpenVMS

    On Mon, 18 Aug 2008 06:44:19 -0700, Bob Koehler
    wrote:

    > In article , "Tom Linden"
    > writes:
    >>
    >> Well I have always disabled fingerd whether on Unix or VMS, but there
    >> may well be other avenues. Such exploits would not be possible had the
    >> code
    >> been written using a safe language like PL/I or Ada with apporpriate
    >> ON conditions.

    >
    > If I understand correctly, the exploit is not through the finger
    > server (fingerd), but the finger client. Is your finger client
    > disabled?
    >

    Yes.


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

  16. RE: DEFCON 16 and Hacking OpenVMS

    In article <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED5D1F0F0@GVW1158 EXB.americas.hpqcorp.net>, "Main, Kerry" writes:
    >
    > Did you not see the announcement at?
    > http://h71000.www7.hp.com/network/new.html
    >


    Well, that is just great. :-(

    There's a standard place within HP for posting patches:

    ftp://ftp.itrc.hp.com/openvms_patches

    but instead, the UCX team have decided to go and place their patches at
    a non-standard location that we are not going to find unless we are told
    about it, in the way that you have just told us.

    The ITRC location is the place to go for patches, and there are automated
    tools that scan this location and notify the system manager of any new
    patches.

    Are there any other private locations within the VMS world for patches
    that various teams have setup that we should be aware of ? :-(

    I also note that the UCX team didn't provide a .TXT file detailing the
    contents of the patch. A .TXT file is also standard VMS patch procedure.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

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

    In article
    ,
    bugs@signedness.org wrote:

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


    I think the key to this mystery is that a lot of us simply haven't used
    finger on VMS. I know I have never enabled it on a VMS system, and
    suspect that I am not alone.

    --
    Paul Sture

  18. Re: DEFCON 16 and Hacking OpenVMS


    "Simon Clubley" wrote in message
    news:U8rSo55epjHX@eisner.encompasserve.org...

    > The ITRC location is the place to go for patches, and there are automated
    > tools that scan this location and notify the system manager of any new
    > patches.


    When they have a proper patch, they will put it there - at the moment it's
    just a replacement image. I don't think there is much sense in complaining
    about the existance of a hotfix; it's not as if anyone will learn anything new
    by reverse engineering it. Feel free to complain about the timeliness of
    a formal patch though



  19. Re: DEFCON 16 and Hacking OpenVMS

    In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    >In article <48a623a0$0$18525$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >> VAXman- @SendSpamHere.ORG wrote:
    >>
    >>> Memory is readable-only or read-write on Alpha. There's nothing in the
    >>> PTE on VMS to indicate that it is or is not executable instruction code.

    >>
    >> Oh wow. I was way off then. Was this the case for VAX where memory would
    >> be tagged as executable or not ?

    >
    > On both VAX and Alpha, executable vs. non-executable PSECTS are just
    > notes to the linker because programs page more efficiently if you
    > keep the executable code together. VAX and Alpha do not enforce
    > noexe at runtime.
    >
    > Alpha's Macro-32 (and I think Macro-64) does complain if you put code
    > in a noexe PSECT, or data in an exe PSECT, but you are at liberty to
    > ignore it. It just slows your program down.


    There is a MIXED attribute in Macro64. I've used this extensively.

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

  20. Re: DEFCON 16 and Hacking OpenVMS

    In article , "Richard Brodie" writes:
    >
    > "Simon Clubley" wrote in message
    > news:U8rSo55epjHX@eisner.encompasserve.org...
    >
    >> The ITRC location is the place to go for patches, and there are automated
    >> tools that scan this location and notify the system manager of any new
    >> patches.

    >
    > When they have a proper patch, they will put it there - at the moment it's
    > just a replacement image. I don't think there is much sense in complaining
    > about the existance of a hotfix; it's not as if anyone will learn anything new
    > by reverse engineering it. Feel free to complain about the timeliness of
    > a formal patch though
    >


    It's not the existance of the hotfix that I am complaining about, but the
    lack of a formal announcement in the proper location, so that those of us
    who look in the proper place for patches or use scanning tools will find it.

    If the file is not a formal patch, which I thought it was based on Kerry's
    response, then my original comment stands.

    Kerry, where's the formal patch and the formal announcement ?

    It's unacceptable that there hasn't been a formal patch by now.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

+ Reply to Thread
Page 11 of 35 FirstFirst ... 9 10 11 12 13 21 ... LastLast