INFO-VAX Mon, 18 Aug 2008 Volume 2008 : Issue 450 Contents: 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: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Not Invented Here (Re: DEFCON 16 and Hacking OpenVMS) ---------------------------------------------------------------------- Date: Sun, 17 Aug 2008 12:30:23 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <94b9759b-b765-47ff-8d40-72509fee0bed@a70g2000hsh.googlegroups.com> On Aug 17, 7:11=A0pm, JF Mezei wrote: > b...@signedness.org wrote: > > No, we came to an VMS group that already discussed the vulnerabilities > > that we found and claimed that they were lies and a hoax. > > Initially, you were unable to explain this issue in terms that were > credible because you spoke "chinese" with terms that are foreign to VMS. > > > We are sorry that we assumed that you guys > > knew what shellcode was, it is a common used description in SECURITY > > Your message sounded like you had found a Unix bug in VMS and knew > nothing of VMS, so it is perfectly normal that many doubted you were > legit since you were unable to give details we could understand > initially. It took a lot of discussion and a translator to give us a > clue on what the actual vulnerability was. > > > It is laughable that there are still people working with security > > in IT that does not know what shellcode is. > > VMS has not had many security hackers in the last couple of decades, so > you are correct that we don't know about all the terminology used by > hackers. > > we don't use the term "shell" in VMS, and to us, it means someone coming > from Unixland, and it refers to the shell (in VMS terms, DCL, or in Unix > terms Bash etc). Shellcode would then be seen as shell scripts. > > > There was attempts to try to clarify this, for example by Simon > > Clubley: > > Correct. And after we were able to translate "shellcode" into something > meaningful like "machine code", then we could understand what you were > talking about. Had you begun with "machine code", then there would have > been less confusion. > > Also, initially, it was assumed you were talking about DCL. But it is > only once it was revealed that you needed to be inside an application > that uses the CLI routines that things started to fall into place. > > > That is exactly what we did, except that we used "address to jump to" > > and > > "return address" instead of "followed by four bytes". I'm not even > > going > > to quote that post. > > YOu did not state it in those terms. You used terms like shellcode. And > you also mixed in the finger thing which confused a lot since it appears > to be a totally separate problem. > > > But that was obviously not clear enough, since we are not VMS-people, > > and theirfore can not be fully trusted: > > Please understand that this is a fairly small community and when some > newcomer comes in with some fantastic claims, there is to be some > serious questioning to establish the credibility of that person, and > since you did not know VMS terminology, it was hard to take you so > seriously. > > > VAXman did not even bother to watch the videos, he continued to > > mess with DCL even though we nicely pointed out that the bug > > was located elsewhere. He also did not listen to us when we explained > > why FILE.EXE is used. > > 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. > > 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. > > You should have stuck to "enter 511 bytes, up up up, and a 4 byte binary > value, and the application will then branch to that binary value, and > any code located there runs with whatever privileges the application had > enabled at that time. > > Then, you could have introduced the concept of branching to some machine > code stored in memory via a logical name. And then the concept of that > machine code using SYS$CREPRC to create a suboprocess which has > inherited whatecer privileges were enabled inside of the main application= . > > The way you presented it initially appeared to be a mismash of various > random terms that didn't apply to VMS, and made us even doubt that when > you used "logical" you really meant a VMS logical name. Mentioning that > the logical was created in the process logical name table would have > assured us you knew what a logical name was. (this is a concept foreign > to unix and DOS/windows). > > > It is not irrelevant when trying to describe what the exploit actually > > does, > > Your implementation is not really necessary. Mentioning that an > installed image can be made to branch to any random location in memory > which can potentially execute your own code is sufficient to get most fo > the folks here to understand the real problem. > > Also, I beleive that someone mentioned "crash the system". =A0But it is > really crash the application. Again, terminology that made the issue > lose credibility. > > > obviously there are people that have a great trouble understanding the > > basics of the exploit since questions with trivial answers has been > > repeated > > all over the thread. > > Now that it has been explained in terms we understand, we understand the > problem. > > > In fact, we know very little about the system itself, we find > > vulnerabilities and write PoC code to proof that the vulnerabilities > > exist. > > And this is why it was hard for many of us to take you seriously. > Remember that you barged into a small community with a "the theatre is > on fire" and then used language that made it look like you thought the > theratre was on fire because you saw a blinking light. > > I think you assumed everyone knew your terminology and that is why > things turned sour. Just be aware of that next time you find a problem > with an OS with which you are not familiar. > > > people trying to secure your system you should perhaps be a bit humble > > and TRY to understand so that problems can be solved. > > The next step is for you to spill the beans on exactly whom you > contacted at HP so that we can try to find out if HP is taking thsi > seriously or not. Contrary to Linux, we can't fix bugs that are found > and depend on a dwindling supply of VMS engineers > =A0to fix them and depend on some not so great managemenet to decide to > release it or not. Ok, well again.. 1) We didn't come in here with "fantastic claims". Someone showed us this thread, and we replied because people were insinuated that we were full of shit.. We presented a couple of vulnerabilities we found in VMS at security conference that ~8500 people attended. We gave you videos demonstrating one of the bugs (let us know if someone wants the finger exploit vid btw), we also offered to demonstrate the exploit live. Shouldn't that at least give us SOME credibility?? 2) Again with the terminology... When talking about security it make sense to use security terminology, if you don't understand something, then either google it or ask rather than assume.. 3) We brought up finger because people were talking about it and getting that wrong too 4) Someone may have mention "crash the system" but it wasn't us 5) We didn't barge in screaming the theatre is on fire.. We talked about a few vulnerabilities at a conference and gave a few demos. People that didn't see the presentation or even the material assumed we were idiots and/or bullshitting about the vulnerabilities.. Fair enough, VMS users may not be used to receiving bug reports or deal with security vulnerabilities, the rest I don't buy... I recommend you change your attitudes though, and don't put people off from reporting them because there are LOTS of them.. We contacted security-alert@hp.com , as far as I can understand they assigned a person to the case and at least one other HP person was cc'd in on the communication until they stopped replying (I don't think it is necessary to out their names).. ------------------------------ Date: Sun, 17 Aug 2008 13:36:31 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <9cb196c9-0f59-4b87-b9d4-6a1ad73db2e8@w7g2000hsa.googlegroups.com> On Aug 17, 2:26=A0pm, JF Mezei wrote: > I would still be interested to know what the up-arrow 3 times actually > does to trigger this issue. Nothing much. It's just a convenient way to enter a since escape followed by some more characters. But any 'other' escape will do. The up-arrow is irrelevant. > Does SMG use $QIO's terminal driver capabilities to read input (such as > detecting ansi sequences) or does it call $QIO for raw input and SMG > does all the interpretation itself ? Both. It uses the IO$M_ENTEND functionality for some input, plani QIOs for other. In the trouble zone highlighted here it is doing simple single character IOs with a 3 second timeout. They are there for all to see using System Service Login. You can use MAIL or anything else using SMG, but a simple test program is preferred to minimize the clutter. Having CMEXEC or better is recommended for a full view but not critical. $SPAWN ! Easy cleanup $SET PROC/SSL=3D(STAT=3DON,FLAG=3DARG) $RUN smg_test $TYPE something ! Easy reference in log $SET PROC/SSL=3DSTAT=3DUN $LOGOUT $ANAL/SSL/SELECT=3DACCES=3DUSER ---- smg_test.c ---- #include int smg$create_virtual_keyboard(), smg$read_composed_line(); int s,i,keyboard_id; struct dsc$descriptor_d result =3D { 0, DSC$K_DTYPE_T, DSC$K_CLASS_D, 0 }; $DESCRIPTOR(prompt,"Test:"); main() { s =3D smg$create_virtual_keyboard(&keyboard_id); while (s & 1) { s =3D smg$read_composed_line(&keyboard_id,0,&result,&prompt); } return(s); } > > Consider the possibility that this would be a terminal driver problem: I did. And came to the conclusion it is not. > with SET TERM/UNKNOWN, the $QIO might continue to add data to the buffer > even though $QIO was told to not write anything beyond 511 bytes. And > this writing would done at the driver level. That would be scary huh? But that's not something we expect from OpenVMS. Hein. ------------------------------ Date: Sun, 17 Aug 2008 14:03:45 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <4a9cfc5f-f766-43ce-a025-01b977cf6ce2@25g2000hsx.googlegroups.com> On Aug 17, 1:40=A0pm, Mark Daniel wrote: : > Interestingly, it reproduces readily on a up-to-date Alpha but NOT on an > up-to-date Itanium: HP rx2600 (900MHz/1.5MB), OpenVMS I64 V8.3-1H1. It's the same code on Itanium. Same problem, just a touch harder to exploit. $ show cpu System: TD183, HP rx2600 (1.40GHz/1.5MB) $ run tmp Test:123456789012..... %SYSTEM-F-ACCVIO, access violation, reason mask=3D00, virtual address=3D000000002D2D2D2D, PC=3D000000007AE1BA90, PS=3D0000001B The virtual addres is one I picked: "ascii dashes", As you seen the PC was not. Might be impossible to exploit, might just be harder. Not my problem. I'm just happy this topic was 'just a warning', and not a full exploit description. Nice reality check! The description came pretty darn close to a full exploit description, no thanks to the initial apprehension expressed. In fact it came too close for some readers.. they manged to figure it out. If indeed the HP security hotline failed to listen to the warnings then shame on them! Cheers, Hein. Hein. ------------------------------ Date: Sun, 17 Aug 2008 15:31:32 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 16, 12:01 pm, b...@signedness.org wrote: > On Aug 16, 4:26 am, Hein RMS van den Heuvel > > > > wrote: > > On Aug 15, 8:37 pm, VAXman- @SendSpamHere.ORG wrote: > > > > In article , JON...@ecr= 6.ohio-state.edu (David Jones) writes: > > > > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegr= oups.com>, > > > > b...@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. > > 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. Been away over the weekend, just catching up, not going to comment on the techy stuff as you now seem to have convinced those here who needed convincing, which is good, and the details are now clear enough (which is arguably not so good, but hey). Hopefully those in HP who needed convincing already were convinced and are suitably motivated to be in the process of fixing it. Which just leaves me to add... > "I think your comment says more about the attitudes in the VMS community > than it says about our lack of experience with VMS." Does any of this discussion say anything worthwhile about attitudes in the broader VMS community (ie including the invisible ones, not just contributors here)? Not sure it does. But thank you (from me at least) for the wake up call. ------------------------------ Date: Sun, 17 Aug 2008 15:49:03 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <29a24b71-aaeb-4ec0-8f36-7dac66a92b21@8g2000hse.googlegroups.com> On Aug 17, 10:03=A0pm, Hein RMS van den Heuvel wrote: > On Aug 17, 1:40=A0pm, Mark Daniel wrote: > : > > > Interestingly, it reproduces readily on a up-to-date Alpha but NOT on a= n > > up-to-date Itanium: HP rx2600 (900MHz/1.5MB), OpenVMS I64 V8.3-1H1. > > It's the same code on Itanium. > Same problem, just a touch harder to exploit. > > $ show cpu > System: TD183, HP rx2600 =A0(1.40GHz/1.5MB) > > $ run tmp > Test:123456789012..... > %SYSTEM-F-ACCVIO, access violation, reason mask=3D00, > virtual address=3D000000002D2D2D2D, PC=3D000000007AE1BA90, PS=3D0000001B > > The virtual addres is one I picked: "ascii dashes", > As you seen the PC was not. > Might be impossible to exploit, might just be harder. > Not my problem. > > I'm just happy this topic was 'just a warning', and not a full exploit > description. > Nice reality check! > > The description came pretty darn close to a full exploit description, > no thanks to the initial apprehension expressed. > In fact it came too close for some readers.. they manged to figure it > out. > > If indeed the HP security hotline failed to listen to the warnings > then shame on them! > > Cheers, > Hein. > > Hein. =46rom the output it looks like you might be overwriting and deferencing a pointer there before a saved return address is used (I'm guessing the itanium compiler arranges local stack variables differently). I don't have access to a itanium box so I can't say for sure how difficult it would be to exploit there. The things I can think of that *might* make exploitation harder is if it is a 64bit pointer being overwritten and you can't write NULL bytes through the overflow vector (not very familiar with the virtual address layout but I'm guessing it could be a problem you'd have to solve).. Of course the pointer deref might offer new possibilities for exploitation too. I my guess it that it would be more or less trivial to exploit itanium too. btw those of you with a patched finger client could you verify that the bug not discussed here so far (reading files with sysprv by link()'ing them to .plan) also been patched? ------------------------------ Date: 17 Aug 2008 23:18:58 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In message "Tom Linden" writes: >I have been following this discussion a bit. Is it correct to assume that >what is going on is overflowing a presumed 512 byte buffer with a presumed >null-terminated string as the first step in the exploit, and this is in >SMG? SMG is written in BLISS. and the code in question (if I've analyzed it correctly) is not overflowing the buffer because a null is missing. It reserved space for a 5 character escape sequence and doesn't do ANY limit check (though possibly wrapping at 65K). The bug has probably been in the code longer than DEFCONs have been around. David L. Jones | Phone: (614) 271-6718 Ohio State University | Internet: 140 W. 19th St. | jonesd@ecr6.ohio-state.edu Columbus, OH 43210 | vman+@osu.edu Disclaimer: I'm looking for marbles all day long. ------------------------------ Date: Sun, 17 Aug 2008 19:17:32 -0500 From: patrick jankowiak Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: %%%%%%%%%%%%%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. ------------------------------ Date: Sun, 17 Aug 2008 17:35:38 -0700 From: "Tom Linden" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Sun, 17 Aug 2008 16:18:58 -0700, David Jones wrote: > SMG is written in BLISS. and the code in question (if I've analyzed it > correctly) is not overflowing the buffer because a null is missing. It > reserved space for a 5 character escape sequence and doesn't do ANY limit > check (though possibly wrapping at 65K). The bug has probably been in > the > code longer than DEFCONs have been around. Which module and line number in the listings? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sun, 17 Aug 2008 17:49:31 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 18, 12:25=A0am, "Richard Maher" wrote: > Hi > > <<<<<<<<<<<<<<<<<<< > We contacted security-al...@hp.com , as far as I can understand they > assigned a person to the case and at least one other HP person was > cc'd in on the communication until they stopped replying (I don't > think it is necessary to out their names).. > > > > I'm guessing patches, regression-testing, =A0and kitting take time, but i= f you > have seen a legitimate security hole report ignored or fobbed-off then I > think it is absolutely necessary that you out their names! God knows > something has to change in that place; every little helps. > > Regards Richard Maher > > PS. I think just a little more boastfulness and triumphalism might really > help things :-) > > wrote in message > > news:94b9759b-b765-47ff-8d40-72509fee0bed@a70g2000hsh.googlegroups.com... > On Aug 17, 7:11 pm, JF Mezei wrote: > > > > > b...@signedness.org wrote: > > > No, we came to an VMS group that already discussed the vulnerabilitie= s > > > that we found and claimed that they were lies and a hoax. > > > Initially, you were unable to explain this issue in terms that were > > credible because you spoke "chinese" with terms that are foreign to VMS= . > > > > We are sorry that we assumed that you guys > > > knew what shellcode was, it is a common used description in SECURITY > > > Your message sounded like you had found a Unix bug in VMS and knew > > nothing of VMS, so it is perfectly normal that many doubted you were > > legit since you were unable to give details we could understand > > initially. It took a lot of discussion and a translator to give us a > > clue on what the actual vulnerability was. > > > > It is laughable that there are still people working with security > > > in IT that does not know what shellcode is. > > > VMS has not had many security hackers in the last couple of decades, so > > you are correct that we don't know about all the terminology used by > > hackers. > > > we don't use the term "shell" in VMS, and to us, it means someone comin= g > > from Unixland, and it refers to the shell (in VMS terms, DCL, or in Uni= x > > terms Bash etc). Shellcode would then be seen as shell scripts. > > > > There was attempts to try to clarify this, for example by Simon > > > Clubley: > > > Correct. And after we were able to translate "shellcode" into something > > meaningful like "machine code", then we could understand what you were > > talking about. Had you begun with "machine code", then there would have > > been less confusion. > > > Also, initially, it was assumed you were talking about DCL. But it is > > only once it was revealed that you needed to be inside an application > > that uses the CLI routines that things started to fall into place. > > > > That is exactly what we did, except that we used "address to jump to" > > > and > > > "return address" instead of "followed by four bytes". I'm not even > > > going > > > to quote that post. > > > YOu did not state it in those terms. You used terms like shellcode. And > > you also mixed in the finger thing which confused a lot since it appear= s > > to be a totally separate problem. > > > > But that was obviously not clear enough, since we are not VMS-people, > > > and theirfore can not be fully trusted: > > > Please understand that this is a fairly small community and when some > > newcomer comes in with some fantastic claims, there is to be some > > serious questioning to establish the credibility of that person, and > > since you did not know VMS terminology, it was hard to take you so > > seriously. > > > > VAXman did not even bother to watch the videos, he continued to > > > mess with DCL even though we nicely pointed out that the bug > > > was located elsewhere. He also did not listen to us when we explained > > > why FILE.EXE is used. > > > 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. > > > 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. > > > You should have stuck to "enter 511 bytes, up up up, and a 4 byte binar= y > > value, and the application will then branch to that binary value, and > > any code located there runs with whatever privileges the application ha= d > > enabled at that time. > > > Then, you could have introduced the concept of branching to some machin= e > > code stored in memory via a logical name. And then the concept of that > > machine code using SYS$CREPRC to create a suboprocess which has > > inherited whatecer privileges were enabled inside of the main applicati= on. > > > The way you presented it initially appeared to be a mismash of various > > random terms that didn't apply to VMS, and made us even doubt that when > > you used "logical" you really meant a VMS logical name. Mentioning that > > the logical was created in the process logical name table would have > > assured us you knew what a logical name was. (this is a concept foreign > > to unix and DOS/windows). > > > > It is not irrelevant when trying to describe what the exploit actuall= y > > > does, > > > Your implementation is not really necessary. Mentioning that an > > installed image can be made to branch to any random location in memory > > which can potentially execute your own code is sufficient to get most f= o > > the folks here to understand the real problem. > > > Also, I beleive that someone mentioned "crash the system". But it is > > really crash the application. Again, terminology that made the issue > > lose credibility. > > > > obviously there are people that have a great trouble understanding th= e > > > basics of the exploit since questions with trivial answers has been > > > repeated > > > all over the thread. > > > Now that it has been explained in terms we understand, we understand th= e > > problem. > > > > In fact, we know very little about the system itself, we find > > > vulnerabilities and write PoC code to proof that the vulnerabilities > > > exist. > > > And this is why it was hard for many of us to take you seriously. > > Remember that you barged into a small community with a "the theatre is > > on fire" and then used language that made it look like you thought the > > theratre was on fire because you saw a blinking light. > > > I think you assumed everyone knew your terminology and that is why > > things turned sour. Just be aware of that next time you find a problem > > with an OS with which you are not familiar. > > > > people trying to secure your system you should perhaps be a bit humbl= e > > > and TRY to understand so that problems can be solved. > > > The next step is for you to spill the beans on exactly whom you > > contacted at HP so that we can try to find out if HP is taking thsi > > seriously or not. Contrary to Linux, we can't fix bugs that are found > > and depend on a dwindling supply of VMS engineers > > to fix them and depend on some not so great managemenet to decide to > > release it or not. > > Ok, well again.. > > 1) We didn't come in here with "fantastic claims". Someone showed us > this thread, and we replied because people were insinuated that we > were full of shit.. We presented a couple of vulnerabilities we found > in VMS at security conference that ~8500 people attended. We gave you > videos demonstrating one of the bugs (let us know if someone wants the > finger exploit vid btw), we also offered to demonstrate the exploit > live. Shouldn't that at least give us SOME credibility?? > > 2) Again with the terminology... When talking about security it make > sense to use security terminology, if you don't understand something, > then either google it or ask rather than assume.. > > 3) We brought up finger because people were talking about it and > getting that wrong too > > 4) Someone may have mention "crash the system" but it wasn't us > > 5) We didn't barge in screaming the theatre is on fire.. We talked > about a few vulnerabilities at a conference and gave a few demos. > People that didn't see the presentation or even the material assumed > we were idiots and/or bullshitting about the vulnerabilities.. > > Fair enough, VMS users may not be used to receiving bug reports or > deal with security vulnerabilities, the rest I don't buy... I > recommend you change your attitudes though, and don't put people off > from reporting them because there are LOTS of them.. > > We contacted security-al...@hp.com , as far as I can understand they > assigned a person to the case and at least one other HP person was > cc'd in on the communication until they stopped replying (I don't > think it is necessary to out their names).. Hi, thanks for your your support.. :) I don't think we have to be more boastful. Seems that people starting to accept that even VMS have really simple bugs and I'm sure this will lead to more people looking at VMS security. If that doesn't happen, well then we may have to "come out of retirement" with more bugs.. ------------------------------ Date: Sun, 17 Aug 2008 19:58:10 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: 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 is a bug for you to analyze. ------------------------------ Date: Sun, 17 Aug 2008 20:03:51 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 17, 7:18=A0pm, JON...@ecr6.ohio-state.edu (David Jones) 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? ------------------------------ Date: Sun, 17 Aug 2008 23:36:48 -0400 From: "Ken Robinson" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <7dd80f60808172036j7b782f35sedddba9029372a0a@mail.gmail.com> 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. 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. Ken Robinson ------------------------------ Date: Sun, 17 Aug 2008 20:53:27 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 18, 5:19 am, JF Mezei wrote: > b...@signedness.org wrote: > > played around with DCL commands and asked about FILE.EXE in the first > > place. > > While battling headwids today on my bike, I was thinking about this. > > You had machine code being executed as part of a utility like INSTALL. > This would be running inside that process and inherit all of the > process' profile. You mentioned that this machine code created a > subprocess with SYS$CREPRC, and that subprocess ran that FILE.EXE, correct ? Yeah, correct. > Now, if that subprocess was created to run FILE.EXE, it means that it > would not have a DCL environment below it, and not have access to many > functions. > > What you could have done is create a subprocess that runs > SYS$SYSTEM:LOGINOUT.EXE with input being the current terminal device, > and output being the currnet terminal device (you would have then had > access to the $ sign and any DCL commands). > > Alternatively, you could have had the input set to a file containing DCL > command (a command procedure (aka: unix shell script) and that command > procedure would have had full access to SHOW PROCESS/OUTPUT=xxx or RUN > FILE.EXE. > > Finally, the machine code stub that you had "embedded" into the utility > in the mother process (via a logical name) would need to know a bit more > about how it is being called. > > If the utility simply branches to your code, then your code would have > no way of knowing where to branch back once it has completed its work. > If the utility calls your code as a subroutine, then you could do all > you want inside your subroutine and return to the caller cleanly and let > the utility continue it merry way. > > However, the utility might expect some results from that subroutine and > if your covert code-in-a-logical doesn't provide those results, the > mainline code from the utility might barf with some invalid data. > > AKA: it would be pretty hard to make it appear totally transparent so > that the user would have no knowledge that something untowards was done > behind the scenes. Interesting ideas, thanks a lot. The calling standard for sub routines are not totally clear to us, but it could be worth looking into further for a better exploit, thanks again. Btw, any suggestions on how to trigger this automatically without using a custom telnet/ssh client? 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. Is there a way to control another process locally like the expect program does on Unix? ------------------------------ Date: Sun, 17 Aug 2008 21:00:31 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: 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 ------------------------------ Date: 18 Aug 2008 05:10:19 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: 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. David L. Jones | Phone: (614) 271-6718 Ohio State University | Internet: 140 W. 19th St. | jonesd@ecr6.ohio-state.edu Columbus, OH 43210 | vman+@osu.edu Disclaimer: I'm looking for marbles all day long. ------------------------------ Date: Sun, 17 Aug 2008 22:25:37 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <7e4da763-90c8-4464-aae8-cae4ecba6d23@x41g2000hsb.googlegroups.com> On Aug 18, 7:10 am, JON...@ecr6.ohio-state.edu (David Jones) wrote: > 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? Nah, we just want to make the exploit a little better. If the intention was to create malicious software we would probably have greater success if we did not report this vulnerability. :) > 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. Thank you! We will look into this. ------------------------------ Date: Mon, 18 Aug 2008 07:19:47 +0800 From: "Richard Maher" Subject: Not Invented Here (Re: DEFCON 16 and Hacking OpenVMS) Message-ID: Hi "bugs", >>>>>>>>>>>>>>>>>> 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. <<<<<<<<<<<<<<<<<<<< Being realtively new to VMS you're probably also new to comp.os.vms. You must understand that you're presentation skills, grammer, spelling and color choices are evryting here, and the substance you post often deemed irrelevant. (Just lucky you didn't top-post or you would've been kill-filed on principle :-) There are pecking-orders, mutual-admiration societies, and poisonous-cliques, to be maintained and etiquette is paramount. (A philosophy, organizational-structure, and attitude based soley on VMS Middle-management's own.) Science and technology are rarely discussed in this forum anymore and certainly not with the same passion reserved for global-warming, us-politics, or "the good ol' days". In fact, any discussion of "the outside world" tends to unsettle the residents so it'd be really helpful if you could keep such loose-talk to a minimum. Ousiders, tall-poppies, in fact anyone who doesn't share the same 95% of chromosomes and has been kissing the usual Digital arses for 25 years will be treated with the same distain from the royal order of xenophobic banjo-pluckers. This vulnerability was clearly for one of The Annointed to discover and one really must know one's place :-( Anyway, if nothing else, I for one am grateful for the interest this has once again generated in VMS! (And please continue *your* interest in what, I sure you'll discover, is still the best server os on the market.) And if there are more vulnerabilities and exploits out there then please throw them up so that someone can swat them. Well done! Regards Richard Maher PS. Is the latest that this bug is being put down to smg$ and that any smg$ RTL-using image installed with privs in vulnerable? Yikes! How long d'ya reakon that hole has been open? wrote in message news:ad17ec3e-cab9-476f-ba1e-34118a632598@c58g2000hsc.googlegroups.com... On Aug 16, 4:26 am, Hein RMS van den Heuvel wrote: > On Aug 15, 8:37 pm, VAXman- @SendSpamHere.ORG wrote: > > > In article , JON...@ecr6.ohio-state.edu (David Jones) writes: > > > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups.com>, > > > b...@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. > 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=(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öderholm, 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)... ¨ 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öderholm 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. ------------------------------ End of INFO-VAX 2008.450 ************************