INFO-VAX Sat, 16 Aug 2008 Volume 2008 : Issue 447 Contents: Re: Avoid printing of SYS$ANNOUNCE ? Re: Avoid printing of SYS$ANNOUNCE ? Copying name database in DECNet-Plus Copying name database in DECNet-Plus Copying name database in DECNet-Plus Copying name database in DECnet-Plus Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DSPP & OpenVMS Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) ---------------------------------------------------------------------- Date: Fri, 15 Aug 2008 23:05:07 -0700 (PDT) From: AEF Subject: Re: Avoid printing of SYS$ANNOUNCE ? Message-ID: On Aug 14, 6:23 pm, moro...@world.std.spaamtrap.com (Michael Moroney) wrote: > I used the SYSMAN ALF feature to set up a hardwired terminal line to > automatically log into a captive account (no Username: prompt) that > automatically runs an application when someone presses return on the > terminal. There are UAF flags to do things like disable the SYS$WELCOME > message, but none for disabling SYS$ANNOUNCE. (Since SYS$ANNOUNCE > normally gets displayed before the Username: prompt, it makes sense > that there can't be a NOANNOUNCE flag). > > Does anyone know of a way to disable the display of SYS$ANNOUNCE on a > terminal-by-terminal basis? > > Related question: Is there a way to disable the "logged out" message at > the end when a process is logged out? Actually I know an answer to this, > $ STOP/ID=0. But that seems so crude, is there _another_ way to do that? Buy another system and form a VMScluster with your existing system. Connect the hard-wired terminals to one system and set it up so that everyone else connects to the other. Set up different SYS$ANNOUNCE's on each system. I don't know how to solve your logout problem. I think you're stuck with STOP/ID=0. AEF ------------------------------ Date: Sat, 16 Aug 2008 14:26:22 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Avoid printing of SYS$ANNOUNCE ? Message-ID: AEF writes: >Buy another system and form a VMScluster with your existing system. >Connect the hard-wired terminals to one system and set it up so that >everyone else connects to the other. Set up different SYS$ANNOUNCE's >on each system. Not really possible. This isn't a real high priority, it's just that I want things to look better. I want to log terminal sessions. I have a captive account that does the equivalent to SET HOST/LOG 0 to log the terminal session. (I don't actually use SET HOST/LOG since I want the log file to be sharable but that's another story). Right now the users see SYS$ANNOUNCE twice, once for the captive account and once for the logged session. On logout you see a logout message twice, once for the logged session and oncec for the captive account. Not a big deal, it just looks funny. >I don't know how to solve your logout problem. I think you're stuck >with STOP/ID=0. ------------------------------ Date: Sat, 16 Aug 2008 08:23:58 -0700 (PDT) From: sampsal@gmail.com Subject: Copying name database in DECNet-Plus Message-ID: <25879dec-8d2c-44c8-a10b-531467b3f176@e53g2000hsa.googlegroups.com> How does one go about copying the name database from another host in DECnet-Plus ------------------------------ Date: Sat, 16 Aug 2008 08:23:59 -0700 (PDT) From: sampsal@gmail.com Subject: Copying name database in DECNet-Plus Message-ID: How does one go about copying the name database from another host in DECnet-Plus ------------------------------ Date: Sat, 16 Aug 2008 08:23:59 -0700 (PDT) From: sampsal@gmail.com Subject: Copying name database in DECNet-Plus Message-ID: How does one go about copying the name database from another host in DECnet-Plus ------------------------------ Date: Sat, 16 Aug 2008 08:26:00 -0700 (PDT) From: sampsal@gmail.com Subject: Copying name database in DECnet-Plus Message-ID: How does one go about copying the name database from another host (running PhaseIV) in DECnet-Plus? NCP COPY KNOWN NODES FROM doesn't work, simply gives me a "%SYSTEM-E-UNSUPPORTED, unsupported operation or function" message. I am able to do a SET HOST to the target node if I specify a numeric address for it. (Yes I'm completely new to DECnet). Sampsa ------------------------------ Date: Sat, 16 Aug 2008 03:57:44 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 11:00=A0pm, JF Mezei wrote: > Does the 511 character recall buffer thing crash the system, the process > or just the application that was running at the time ? Sorry for the confusion, JF. It simply generates an access violation in the process that was running at the time. Not a system crash. The process terminates and you're returned to DCL. However, given that the address where the access violation occurs can be predetermined, I at least can see that it is possible to exploit the problem as has been described already. For example, TCPIP is installed with CMKRNL. If you do this with TCPIP as the application instead of MAIL then you can end up with a situation where an unprivileged user has free access to CMKRNL. ------------------------------ Date: Sat, 16 Aug 2008 04:01:21 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 16, 4:26=A0am, Hein RMS van den Heuvel wrote: > On Aug 15, 8:37=A0pm, VAXman- =A0@SendSpamHere.ORG wrote: > > > In article , JON...@ecr6.= ohio-state.edu (David Jones) writes: > > > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegrou= ps.com>, > > > =A0b...@signedness.org writes: > > >>To find the address of a logical you can write a small program that > : > > I fail to see why this code, if it can be executed, must be stored in a > > logical name block's translation region which may be somewhat arduous t= o > > locate > > Best I understand this, the hack needs any address which can be > expressed with a series of ASCII expressable address mappings and > survives image activation. > Logical names are stored in Process Allocation Region (P1 Pool) which > typically starts at (sysgen param dependend) 7Fxxxxxx. So you would > use a '~' for a first char. When I tried one, it started at > "7FF565A0". That F5 would be hard to express. So you would need many > more logicals to eat up space. > An other good zone could be the the Process I/O Segment (PIO). A first > test showed a buffer at 07B0B4400 ($open x login.com $read x y... > $ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel > with bucket size of 60 or so, then you can make the system read 30KB > of 'stuff' into p1 space. > > For a quick address overview: SDA> CLUE PROC/LAYOUT > > fwiw, > Hein. Still fighting jetlag but I'm back to comment on a few things... (some things another presenter already pointed out but they are worth saying again).. 1) People complaining about our terminology.. Well here is the thing, our material was presented at a SECURITY conference so it makes sense to use recognised security terminology, don't you think? 2) Insinuations that we are bullshitting.. Well thats just hilarious coming from people by their own admission triggered one of the bugs (R.A.Omond you may want to read the teso paper on exploiting format string vulnerabilities to understand the output you are getting from finger) 3) Sampsa and johnwalla...@yahoo.co.uk seems to have gotten it mostly right. To johnwalla...@yahoo.co.uk and Jan-Erik S=F6derholm, the reason why you see the access violation in the exploit video is not that the exploit isn't working, the shellcode is executed and executes FILE.EXE. However since we have trashed the stackframe it crashes when it tries to return from the already executed shellcode. The reason you don't often see similar behavior in UNIX exploits is that they often use a shellcode that executes a shell with the execve() system call. execve() replaces the process image and never returns if sucessful.. I hope that clears that up. 4) "There is no such thing as "shellcode" in VMS".. Well shellcode is platform neutral terminology, and while there might not be any public VMS shellcodes we certainly have a few.. 5) JF Mezei, yes we know about the exit() function.. But it would have to be called from the shellcode written in assembler, and as already mentioned it would only be a cosmetic thing since the injected code already been executed. Do YOU know the openvms calling standard on the affected platforms? We just didn't think it was worth the effort.. IF YOU feel it is worth the effort, then you are free to write you own exploit... We never claimed to be VMS experts, infact one of the first thing we mention in the talk is that we are NOT.. However exploiting these bugs are hardly rocket science (again at some point I believe we mentioned that we found it interesting/surprising that such simple bugs still existed in a supposedly secure OS)... For your complaint about our terminology see 1)... =A8 The comment that fair amount of experience with OpenVMS is required to find these bugs is laughable, we had absolutely none when we started looking for bugs. Fair enough there were some obstacles to overcome, like pretty poor debugging environments, tools not working the way we are used to, having to read up on VAX and Alpha asm etc. But in the end an overflow is still an overflow and a format string bug is still a format string bug and if you exploited things like that for the last 10 year or so its not terribly hard to adapt to a new environment. I think your comment says more about the attitudes in the VMS community than it says about our lack of experience with VMS. 6) Bradhamilton, yes we contacted the right people. Had a short dialog with them and then they stopped replying. The two finger bugs we exploited are local priv escalation bugs (well the format string bug anyway). The remote fingerd bug reported by someone at NGS we have not looked at so I can not really comment on that one.. At least on VAX it most likely depends on the C function causing the overflow and the ability of writing NULL bytes, and on alpha I'd assume there would be some interesting problem to solve too.. 7) Hein RMS van den Heuvel. Don't know if you seen the video, but the problem with typing in return address composed of "weird" characters is why we use a homebrewed telnet client. 8) FrankS. Congrats on reproducing it! 9) Wilm Boerhout, well buddy.. We already stated that we won't release any exploits at least until HP released a fix and people had a chance to patch. The finger bug several people here managed to reproduce, in some cases even without realising themselves! See 2). How is that for not being able to recognise a naked, dancing security bug on your head? The cmdline stuff have now been reproduced by FrankS. On top of that we are offering to DEMO the exploit LIVE for anyone that is able to meet up with us.... Maybe you rather want us to release a working exploit before patches are out.. We will keep that in mind for the next set of bugs, maybe you also like to share the IP addresses of your VMS boxes so we can include them in the exploit code for demo purposes? 10) For the naysayers... We already stated that we are not releasing an exploit for this issue at least not until HP patched it and people had a chance to patch. Judging from some email address, there are people from the UK here.. You are all welcome to visit a dc4420 meeting and I'll DEMO the exploit for you LIVE (no video)... Also we are visiting Stockholm in September so assuming he can make it, We'd be happy to show Jan-Erik S=F6derholm or any other Swedish naysayers a live demo. 11) Finally... It is pretty interesting to see peoples reaction to this.. 2 out of 3 PRESENTED issues seems to have been independently verified now. Yet, we are not believed, told to go fuck ourselves, doubted and more or less called liars.. I can understand some healthy scepticism, but maybe you also have some of that to spare for claims of OpenVMS "superior security"...but if you rather take the comfortable "head in sand" position then thats fine by me as long as you don't host any of my data. ------------------------------ Date: Sat, 16 Aug 2008 11:05:49 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E2F6.F9B97841@SendSpamHere.ORG> In article <7f1b0e7d-6901-4426-b337-8498c14cfe06@m73g2000hsh.googlegroups.com>, Hein RMS van den Heuvel writes: >On Aug 15, 8:37=A0pm, VAXman- @SendSpamHere.ORG wrote: >> In article , JON...@ecr6.oh= >io-state.edu (David Jones) writes: >> >> >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups= >..com>, >> > =A0b...@signedness.org writes: >> >>To find the address of a logical you can write a small program that >: >> I fail to see why this code, if it can be executed, must be stored in a >> logical name block's translation region which may be somewhat arduous to >> locate > >Best I understand this, the hack needs any address which can be >expressed with a series of ASCII expressable address mappings and >survives image activation. Surviving image activation I understand. There are many ways to achieve that goal. >Logical names are stored in Process Allocation Region (P1 Pool) which >typically starts at (sysgen param dependend) 7Fxxxxxx. So you would >use a '~' for a first char. When I tried one, it started at >"7FF565A0". That F5 would be hard to express. So you would need many >more logicals to eat up space. OK. Now we're getting somewhere. >An other good zone could be the the Process I/O Segment (PIO). A first >test showed a buffer at 07B0B4400 ($open x login.com $read x y... >$ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel >with bucket size of 60 or so, then you can make the system read 30KB >of 'stuff' into p1 space. > >For a quick address overview: SDA> CLUE PROC/LAYOUT >fwiw, >Hein. BTW, Hein, I've heard nothing more re my question concerning that macro comment. -- 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. ------------------------------ Date: Sat, 16 Aug 2008 11:18:18 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E2F8.B88B38FC@SendSpamHere.ORG> In article , FrankS writes: >On Aug 15, 11:00=A0pm, JF Mezei wrote: >> Does the 511 character recall buffer thing crash the system, the process >> or just the application that was running at the time ? > >Sorry for the confusion, JF. It simply generates an access violation >in the process that was running at the time. Not a system crash. The >process terminates and you're returned to DCL. I've understood that from the posted process stack dumps. >However, given that the address where the access violation occurs can >be predetermined, I at least can see that it is possible to exploit >the problem as has been described already. However, I can't replicate the process stack dumps based upon any of the posted reproducer scenarios to date. >For example, TCPIP is installed with CMKRNL. If you do this with >TCPIP as the application instead of MAIL then you can end up with a >situation where an unprivileged user has free access to CMKRNL. OK. FWIW, I tried with MAIL and left the process active all evening while I was asleep. This morning, it still had not stack dumped. -- 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. ------------------------------ Date: Sat, 16 Aug 2008 04:21:41 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 11:26=A0pm, Hein RMS van den Heuvel wrote: > Best I understand this, the hack needs any address which can be > expressed with a series of ASCII expressable address mappings and > survives image activation. Correct. I haven't played with it as much as the folks that have posted the problem. I'm guessing that if you spawn a subprocess and provide a SYS $INPUT stream you might get around the issue regarding non-printable characters that need to be used to express certain address ranges. The procedures seems to be: - The code which is to be run at elevated privileges (a.k.a. shellcode, I think) needs to be loaded into memory which survives both image rundown (from the application that is storing it in memory) as well as image activation of the application which is installed with elevated privileges (be it TCPIP, INSTALL, TELNET, or any other). - You spawn a subprocess that will load the shellcode as well as activate the privileged application. You also feed the privileged application the 511 + up-up-up + ASCII-expressed shellcode address. - Another curious thing is that it appears the user account doing all this must not have any privileges. I've tried this on my system with a non-privileged (TMPMBX,NETMBX only) account as well as one with all privileges (like SYSTEM). The privileged account doesn't generate the access violation. ------------------------------ Date: Sat, 16 Aug 2008 04:30:40 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <505c7d8b-bcf0-42bc-b7cf-33df7ea7e563@x35g2000hsb.googlegroups.com> On Aug 16, 1:21 pm, FrankS wrote: > On Aug 15, 11:26 pm, Hein RMS van den Heuvel > > wrote: > > Best I understand this, the hack needs any address which can be > > expressed with a series of ASCII expressable address mappings and > > survives image activation. > > Correct. > > I haven't played with it as much as the folks that have posted the > problem. I'm guessing that if you spawn a subprocess and provide a SYS > $INPUT stream you might get around the issue regarding non-printable > characters that need to be used to express certain address ranges. Or write your own SSH/TELNET client as mentioned previously ... In that case you can fully control the return address. Perhaps someone on the list figures this out and posts it so that people like VAXman can belive it. > ------------------------------ Date: Sat, 16 Aug 2008 04:34:24 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <47f42318-d79e-460d-97cf-fed1f5c9eb43@e39g2000hsf.googlegroups.com> On Aug 16, 7:18=A0am, VAXman- @SendSpamHere.ORG wrote: > FWIW, I tried with MAIL and left the process active all evening while I > was asleep. =A0This morning, it still had not stack dumped. By "wait patiently" I meant only seconds, not hours. It may be that a virgin v7.3-2 install doesn't have the bug (it might have been introduced in a later patch), or you're trying it with a privileged account, or something else is different about your environment .vs. mine. Nevertheless, it is reproducable. ------------------------------ Date: Sat, 16 Aug 2008 11:51:57 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E2FD.6C22F584@SendSpamHere.ORG> In article , FrankS writes: >{...snip...} >- You spawn a subprocess that will load the shellcode as well as >activate the privileged application. You also feed the privileged >application the 511 + up-up-up + ASCII-expressed shellcode address. OK. Non-privied account. $ SPAWN MAIL MAIL> AAA(511 of them)AAA Then 3 up-arrows MAIL> @@@@ Which translates to %x40404040 in the lowest regions of P1. I verified using SDA that the page is NOT MAPPED. I should have received an ACCVIO at this address based upon your description of how to reproduce this. I do not. >- Another curious thing is that it appears the user account doing all >this must not have any privileges. I've tried this on my system with >a non-privileged (TMPMBX,NETMBX only) account as well as one with all >privileges (like SYSTEM). The privileged account doesn't generate the >access violation. I have been testing this all along using a non-privied account. In fact, its username is NOPRIV_USER (one of my development test accounts) and has only NETMBX and TMPMBX (otherwise, there would be no SPAWNing). -- 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. ------------------------------ Date: Sat, 16 Aug 2008 08:24:23 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <89fa21b2-3b42-41f1-9f53-604c38ce357b@d45g2000hsc.googlegroups.com> On Aug 16, 3:29=A0pm, "Tom Linden" wrote: > On Sat, 16 Aug 2008 04:34:24 -0700, FrankS wrote: > > On Aug 16, 7:18=A0am, VAXman- =A0@SendSpamHere.ORG wrote: > >> FWIW, I tried with MAIL and left the process active all evening while = I > >> was asleep. =A0This morning, it still had not stack dumped. > > > By "wait patiently" I meant only seconds, not hours. =A0It may be that = a > > virgin v7.3-2 install doesn't have the bug (it might have been > > introduced in a later patch), or you're trying it with a privileged > > account, or something else is different about your environment .vs. > > mine. > > > Nevertheless, it is reproducable. > > How would you go about this on a remote machine to which you do not > have login priveleges? > > -- > PL/I for OpenVMSwww.kednos.com You don't, it is a local priv escalation bug and you need an account on the box to run the exploit from. How you get access to the box in the first place is up to you.. But someone else posted a fingerd overflow that shouldn't be too difficult to exploit, apparently there is a patch out for it but people looking for bugs should have no problem finding more 0day on their own... We would also like to remind group as a whole that it is not too late doubt the validity of our modest claims, call us liars, tell us to go fuck ourselves, hint that the whole thing is a hoax, make outrageous claims about OpenVMS superior security and paint yourself into a corner and comment on matters you have absolute no idea about... Does anyone still doubt the videos are real? Even more interesting question is, does anyone think these are the only exploitable mem corruption type bugs in OpenVMS? Then it REALLY is time to get the head out of the sand and face reality... PS.. We hope VAXman prepared one hell of a proof that he triggered the vuln, because video, independent parties reproducing it and offers to demonstrate it live publically just isn't enough! LOL!!!!! ------------------------------ Date: Sat, 16 Aug 2008 16:10:09 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <48A5FF89.4060903@comcast.net>, bradhamilton writes: >bugs@signedness.org wrote: >[...] >> As stated earlier, we will not release the exploit to the public yet. >> We have informed HP about the problems (we did this about two months >> ago >> together with information about how to reproduce the bugs) >> so there will hopefully be a patch for it in a near future. > >Hopefully, you contacted the "right" people at HP - did you get any kind >of acknowledgment or response? If not, you probably didn't contact the >right people. No fault of yours, and we wouldn't think any less of you. > If you contacted them two months ago, and no patches have appeared >since then, you probably contacted the wrong people. > >The only reason I ask this question is that it is sometimes difficult to >get the attention of the proper people in HP; if you get the "wrong" >folks, the result is the same as singing into a black hole. :-) >[...] > >> Please don't tell us to "fuck off", it makes some of us belive that it >> is >> a good idea to post sensitive information to fd. > >I hope you don't think there is a lot of hostility "here"; it's just >that some of us are used to information that is presented in a format >familiar to us. From initial "reports" of the talk, I (erroneously) >assumed that the talk was about simple DCL bugs. > >All that aside, it seems as though the target must be vulnerable to >begin with; I assume that one vector of "infection" is via the FINGER >server. What happens when your target does not run the server? Are >there other, as yet unknown vectors of "infection" to deliver these >payloads? Are you deliberately setting up your target machine (I assume >under your physical control) to run wide-open, with all known TCP/IP >services enabled (FTP, TELNET, SSH, INETD, etc.)? You would need to >know that practically none of "us" would ever run a VMS machine in such >a fashion. I know that someone, somewhere is probably running a VMS box >like that; if so, they deserve all the exploits they get. :-) >Am I close to being on target here? I can take it if I'm way off; just >tell me in a polite way. :-) We're all willing to learn here, if there >are problems. We await more information. > From what has been posted both these are local privilege escalation vulnerabilities not remotely exploitable vulnerabilites. This one with the CLI interface inside excutables such as Install and the other with the finger client program on the system. David Webb Security team leader CCSS Middlesex University >> And there still is enough information in the previous posts to >> reproduce the bugs on a vulnerable machine. > ------------------------------ Date: Sat, 16 Aug 2008 16:28:46 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , FrankS writes: >On Aug 15, 11:26=A0pm, Hein RMS van den Heuvel > wrote: >> Best I understand this, the hack needs any address which can be >> expressed with a series of ASCII expressable address mappings and >> survives image activation. > >Correct. > >I haven't played with it as much as the folks that have posted the >problem. I'm guessing that if you spawn a subprocess and provide a SYS >$INPUT stream you might get around the issue regarding non-printable >characters that need to be used to express certain address ranges. > >The procedures seems to be: >- The code which is to be run at elevated privileges (a.k.a. >shellcode, I think) needs to be loaded into memory which survives both >image rundown (from the application that is storing it in memory) as >well as image activation of the application which is installed with >elevated privileges (be it TCPIP, INSTALL, TELNET, or any other). > >- You spawn a subprocess that will load the shellcode as well as >activate the privileged application. You also feed the privileged >application the 511 + up-up-up + ASCII-expressed shellcode address. > >- Another curious thing is that it appears the user account doing all >this must not have any privileges. I've tried this on my system with >a non-privileged (TMPMBX,NETMBX only) account as well as one with all >privileges (like SYSTEM). The privileged account doesn't generate the >access violation. I've just retried it on my home VMS 8.3 alpha from a non-privileged account and still can't reproduce it. David Webb Security team leader CCSS Middlesex University ------------------------------ Date: Sat, 16 Aug 2008 10:47:13 -0700 (PDT) From: bradford.hamilton@gmail.com Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 16, 9:34 am, VAXman- @SendSpamHere.ORG wrote: [...] > Dave Jones sent me a private email with one of the details that has > been elided from this discussion. I have now been able to get the > stack dump as previously professed. > > Now to write my so-called "shellcode". > > And then I will up update SecurityGuard to thwart such an attack, if > needed. Thanks for that - I know that there is a problem, and I suspected that we weren't being told the "whole story" until now. ------------------------------ Date: Sat, 16 Aug 2008 09:17:33 -0400 From: "William Webb" Subject: Re: DSPP & OpenVMS Message-ID: <8660a3a10808160617w380688f3t222400fcf415607f@mail.gmail.com> ------=_Part_1872_30652310.1218892653322 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Aug 15, 2008 at 9:39 PM, Richard B. Gilbert wrote: > William Webb wrote: > >> >> >> On Fri, Aug 15, 2008 at 10:12 AM, Richard B. Gilbert < >> rgilbert88@comcast.net > wrote: >> >> Mike R wrote: >> >> On Aug 15, 3:44 pm, clubley@remove_me.eisner.decus.org-Earth.UFP >> (Simon Clubley) wrote: >> >> In article <00A7E234.2282A...@SendSpamHere.ORG>, VAXman- >> @SendSpamHere.ORG writes: >> >> >> >> Technical presales were excellent, but even though the sales >> people within >> HP have had the hard work done from them by the presales >> team, they still >> can't be bothered to put together a quote for me, even >> though it's been >> promised several times now. :-( >> >> >> As a longtime DEC (ex-)customer, and with some experience within >> Dec/ >> Compaq/HP allow me to recommend: >> >> 1. Find the non-responsive person's manager >> 2. Contact same >> 3. If results are unsatisfactory, goto 1. Give up only after 3-4 >> iterations. >> >> >> Remember when you could just ask to speak with the "Manager on Duty"?? >> Those were the "good old days"! >> >> >> You still can, if you have the right level of support. >> >> > > The last time I tried, the person I was talking to hadn't a clue what I was > talking about. H-P person rather than DEC/Compaq person. I eventually got > through to someone who knew what I was talking about and was able to kick > the right butts to get my problem solved. > Another of the magic words is "escalate". Even if the person you're speaking with has no familiarity with the MOD concept, if you keep repeating "escalate", eventually you'll get where you need to be. WWwebb ------=_Part_1872_30652310.1218892653322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Fri, Aug 15, 2008 at 9:39 PM, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
William Webb wrote:



On Fri, Aug 15, 2008 at 10:12 AM, Richard B. Gilbert <rgilbert88@comcast.net <mailto:rgilbert88@comcast.net>> wrote:

   Mike R wrote:

       On Aug 15, 3:44 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
       (Simon Clubley) wrote:

           In article <00A7E234.2282A...@SendSpamHere.ORG>,   VAXman-
            @SendSpamHere.ORG writes:

       <snip...>

           Technical presales were excellent, but even though the sales
           people within
           HP have had the hard work done from them by the presales
           team, they still
           can't be bothered to put together a quote for me, even
           though it's been
           promised several times now. :-(


       As a longtime DEC (ex-)customer, and with some experience within
       Dec/
       Compaq/HP allow me to recommend:

       1. Find the non-responsive person's manager
       2. Contact same
       3. If results are unsatisfactory, goto 1. Give up only after 3-4
       iterations.


   Remember when you could just ask to speak with the "Manager on Duty"??
   Those were the "good old days"!


You still can, if you have the right level of support.
 

The last time I tried, the person I was talking to hadn't a clue what I was talking about.  H-P person rather than DEC/Compaq person.  I eventually got through to someone who knew what I was talking about and was able to kick the right butts to get my problem solved.
 
Another of the magic words is "escalate".  Even if the person you're speaking with has no familiarity with the MOD concept, if you keep repeating "escalate", eventually you'll get where you need to be.
 
WWwebb
------=_Part_1872_30652310.1218892653322-- ------------------------------ Date: Sat, 16 Aug 2008 04:39:55 -0700 (PDT) From: FrankS Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <9ecd93eb-af82-4e8e-a67b-490f1909d176@79g2000hsk.googlegroups.com> On Aug 16, 12:51=A0am, Jeff Campbell wrote: > EVALUATE TRUE =A0will check the state of the variable the 88 condition > values are defined against. It's a shorthand way of saying: Or any other conditional expression ... evaluate true when (myvariable =3D something) perform one-routine when (anythingelse =3D somethingelse) perform two-routine when (yetanotherconditional) perform three-routine when other perform catch-all end-evaluate. It will evaluate each conditional expression in the WHEN clauses until it finds one that is TRUE. ------------------------------ Date: Sat, 16 Aug 2008 07:22:54 -0700 From: "Tom Linden" Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: On Sat, 16 Aug 2008 04:39:55 -0700, FrankS wrote: > On Aug 16, 12:51 am, Jeff Campbell wrote: >> EVALUATE TRUE  will check the state of the variable the 88 condition >> values are defined against. It's a shorthand way of saying: > > Or any other conditional expression ... > > evaluate true > when (myvariable = something) > perform one-routine > > when (anythingelse = somethingelse) > perform two-routine > > when (yetanotherconditional) > perform three-routine > > when other > perform catch-all > end-evaluate. > > It will evaluate each conditional expression in the WHEN clauses until > it finds one that is TRUE. It is basically a copy of a subset of the PL/I SELECT statement. -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2008.447 ************************