DEFCON 16 and Hacking OpenVMSThis is a discussion on DEFCON 16 and Hacking OpenVMS within the VMS forums, part of the Other OS category; > I would have thought a CLI overflow to have been tried by at least a few > at DEFCON9 because the system automagically created service-rich user > accounts with ... | ||||||||
| ||||||||
| Unix Content | Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#21
08-13-2008, 04:22 AM
|
 Re: DEFCON 16 and Hacking OpenVMS > I would have thought a CLI overflow to have been tried by at least a few > at DEFCON9 because the system automagically created service-rich user > accounts with of course DCL which the hackers were then free to abuse. > > We were not scrutinizing buffers however and any such overflow may in > our case have done nothing harmful (by luck or design). I think it was > version 7.1-? if it makes a difference. Did the gentleman specify any > versions? Default 8.3 install on an Alpha according to the presentation notes. To reproduce this, apparently one is to enter exactly 511 characters of input, then press the up arrow three times and wait - a core dump follows. Sampsa  |
|
#22
08-13-2008, 07:12 AM
|
| Re: DEFCON 16 and Hacking OpenVMS sampsal@gmail.com wrote: >> I would have thought a CLI overflow to have been tried by at least a few >> at DEFCON9 because the system automagically created service-rich user >> accounts with of course DCL which the hackers were then free to abuse. >> >> We were not scrutinizing buffers however and any such overflow may in >> our case have done nothing harmful (by luck or design). I think it was >> version 7.1-? if it makes a difference. Did the gentleman specify any >> versions? > > Default 8.3 install on an Alpha according to the presentation notes. > To reproduce this, apparently one is to enter exactly 511 characters > of input, then press the up arrow three times and wait - a core dump > follows. Sorry - I can't reproduce this the way it is described here on my V8.3 Alpha. After entering the characters, and pressing the up arrow three times, I am returned to the "$", without a dump. I have reproduced this technique on two different Alphas, both running V8.3, and have not reproduced the reported behavior. It will be interesting to see the slides. |
|
#23
08-13-2008, 07:30 AM
|
| Re: DEFCON 16 and Hacking OpenVMS In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes: >> I would have thought a CLI overflow to have been tried by at least a few >> at DEFCON9 because the system automagically created service-rich user >> accounts with of course DCL which the hackers were then free to abuse. >> >> We were not scrutinizing buffers however and any such overflow may in >> our case have done nothing harmful (by luck or design). I think it was >> version 7.1-? if it makes a difference. Did the gentleman specify any >> versions? > >Default 8.3 install on an Alpha according to the presentation notes. >To reproduce this, apparently one is to enter exactly 511 characters >of input, then press the up arrow three times and wait - a core dump >follows. I know you didn't make the claim but you should first test it out before brandishing bull**** here. I've tried to reproduce the claimed results from your posted instruction and it does NOT produce a "core dump". -- 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. |
|
#24
08-13-2008, 07:56 AM
|
| Re: DEFCON 16 and Hacking OpenVMS > >Default 8.3 install on an Alpha according to the presentation notes. > >To reproduce this, apparently one is to enter exactly 511 characters > >of input, then press the up arrow three times and wait - a core dump > >follows. > > I know you didn't make the claim but you should first test it out before > brandishing bull**** here. > > I've tried to reproduce the claimed results from your posted instruction > and it does NOT produce a "core dump". Hey don't shoot the messenger, people were interested in what was in the presentation, I just relayed that information WITH THE CAVEAT THAT I DIDN'T TEST IT. They had screenshots of the flaw and source code for an exploit, based on that I assumed it's genuine even if we haven't been able to reproduce it. I'm not trying to scaremonger or stir up ****, in fact I stated in my original post that neither of these exploits seemed particularly earth shattering. Sampsa |
|
#25
08-13-2008, 08:38 AM
|
| Re: DEFCON 16 and Hacking OpenVMS On Wed, Aug 13, 2008 at 7:56 AM, > > >Default 8.3 install on an Alpha according to the presentation notes. > > >To reproduce this, apparently one is to enter exactly 511 characters > > >of input, then press the up arrow three times and wait - a core dump > > >follows. > > > > I know you didn't make the claim but you should first test it out before > > brandishing bull**** here. > > > > I've tried to reproduce the claimed results from your posted instruction > > and it does NOT produce a "core dump". > > Hey don't shoot the messenger, people were interested in what was in > the presentation, I just relayed that information WITH THE CAVEAT THAT > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > an exploit, based on that I assumed it's genuine even if we haven't > been able to reproduce it. > > I'm not trying to scaremonger or stir up ****, in fact I stated in my > original post that neither of these exploits seemed particularly earth > shattering. > > Sampsa > > > There are people in Engineering with whom I can check... WWWebb |
|
#26
08-13-2008, 09:17 AM
|
| Re: DEFCON 16 and Hacking OpenVMS sampsal@gmail.com wrote: >>>Default 8.3 install on an Alpha according to the presentation notes. >>>To reproduce this, apparently one is to enter exactly 511 characters >>>of input, then press the up arrow three times and wait - a core dump >>>follows. >> >>I know you didn't make the claim but you should first test it out before >>brandishing bull**** here. >> >>I've tried to reproduce the claimed results from your posted instruction >>and it does NOT produce a "core dump". > > Hey don't shoot the messenger, people were interested in what was in > the presentation, I just relayed that information WITH THE CAVEAT THAT > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > an exploit, based on that I assumed it's genuine even if we haven't > been able to reproduce it. I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha on which to try. It too failed to fail in any way. Curiously, I just happened to build an off-the-CD V8.3 Alpha only this morning in my workplace (just a pastime unfortunately) and intended to try it there and report tomorrow. Of course it could even be Alpha chip type -specific (fail on an EV56 but not an EV67, etc.) making it more obscure but none-the-less real even if less-than adequately documented. The exploit might be more telling. Thanks for your ongoing reports. > I'm not trying to scaremonger or stir up ****, in fact I stated in my > original post that neither of these exploits seemed particularly earth > shattering. > > Sampsa -- Every year is getting shorter never seem to find the time. Plans that either come to naught or half a page of scribbled lines Hanging on in quiet desperation is the English way The time is gone, the song is over, Thought I'd something more to say. [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] |
|
#27
08-13-2008, 07:02 PM
|
| Re: DEFCON 16 and Hacking OpenVMS On Aug 13, 9:17 am, Mark Daniel > samp...@gmail.com wrote: > >>>Default 8.3 install on an Alpha according to the presentation notes. > >>>To reproduce this, apparently one is to enter exactly 511 characters > >>>of input, then press the up arrow three times and wait - a core dump > >>>follows. > > >>I know you didn't make the claim but you should first test it out before > >>brandishing bull**** here. > > >>I've tried to reproduce the claimed results from your posted instruction > >>and it does NOT produce a "core dump". > > > Hey don't shoot the messenger, people were interested in what was in > > the presentation, I just relayed that information WITH THE CAVEAT THAT > > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > > an exploit, based on that I assumed it's genuine even if we haven't > > been able to reproduce it. > > I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha > on which to try. It too failed to fail in any way. Curiously, I just > happened to build an off-the-CD V8.3 Alpha only this morning in my > workplace (just a pastime unfortunately) and intended to try it there > and report tomorrow. Of course it could even be Alpha chip type > -specific (fail on an EV56 but not an EV67, etc.) making it more obscure > but none-the-less real even if less-than adequately documented. The > exploit might be more telling. Thanks for your ongoing reports. > > > I'm not trying to scaremonger or stir up ****, in fact I stated in my > > original post that neither of these exploits seemed particularly earth > > shattering. > > > Sampsa > > -- > Every year is getting shorter never seem to find the time. > Plans that either come to naught or half a page of scribbled lines > Hanging on in quiet desperation is the English way > The time is gone, the song is over, > Thought I'd something more to say. > [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] $ sh sys VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 19:22:37 $ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %DCL-W-TKNOVF, command element is too long - shorten |
|
#28
08-13-2008, 07:12 PM
|
| Re: DEFCON 16 and Hacking OpenVMS On Aug 13, 7:02 pm, jferraro > On Aug 13, 9:17 am, Mark Daniel > > > > > samp...@gmail.com wrote: > > >>>Default 8.3 install on an Alpha according to the presentation notes. > > >>>To reproduce this, apparently one is to enter exactly 511 characters > > >>>of input, then press the up arrow three times and wait - a core dump > > >>>follows. > > > >>I know you didn't make the claim but you should first test it out before > > >>brandishing bull**** here. > > > >>I've tried to reproduce the claimed results from your posted instruction > > >>and it does NOT produce a "core dump". > > > > Hey don't shoot the messenger, people were interested in what was in > > > the presentation, I just relayed that information WITH THE CAVEAT THAT > > > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > > > an exploit, based on that I assumed it's genuine even if we haven't > > > been able to reproduce it. > > > I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha > > on which to try. It too failed to fail in any way. Curiously, I just > > happened to build an off-the-CD V8.3 Alpha only this morning in my > > workplace (just a pastime unfortunately) and intended to try it there > > and report tomorrow. Of course it could even be Alpha chip type > > -specific (fail on an EV56 but not an EV67, etc.) making it more obscure > > but none-the-less real even if less-than adequately documented. The > > exploit might be more telling. Thanks for your ongoing reports. > > > > I'm not trying to scaremonger or stir up ****, in fact I stated in my > > > original post that neither of these exploits seemed particularly earth > > > shattering. > > > > Sampsa > > > -- > > Every year is getting shorter never seem to find the time. > > Plans that either come to naught or half a page of scribbled lines > > Hanging on in quiet desperation is the English way > > The time is gone, the song is over, > > Thought I'd something more to say. > > [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] > > $ sh sys > VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 > 19:22:37 > > > $ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > _$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > %DCL-W-TKNOVF, command element is too long - shorte Also tried with elevated and from a com file: Username: system Password: Welcome to OpenVMS (TM) VAX Operating System, Version V7.3-2 Last interactive login on Wednesday, 13-AUG-2008 16:31 $ type test.com;1 $ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa $ exit $ @test.com %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters \AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A\ $ WOPR::SYSTEM 19:11:07 (DCL) CPU=00:00:00.89 PF=1373 IO=312 MEM=260 ~~~ Anything else to try? Batch mode? (perhaps I'm not reading it correctly??!??!?!) Joe Ferraro |
|
#29
08-13-2008, 08:30 PM
|
| Re: DEFCON 16 and Hacking OpenVMS On Wed, 13 Aug 2008 16:02:36 -0700, jferraro > $ sh sys > VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 > 19:22:37 I guess I haven't been paying attention, I thought the last version for the VAX was 7.3 -- PL/I for OpenVMS www.kednos.com |
|
#30
08-13-2008, 09:22 PM
|
| Re: DEFCON 16 and Hacking OpenVMS In article <995d1554-09f0-489d-904b-150a9ed48f83@t54g2000hsg.googlegroups.com>, jferraro >On Aug 13, 9:17 am, Mark Daniel >> samp...@gmail.com wrote: >> >>>Default 8.3 install on an Alpha according to the presentation notes. >> >>>To reproduce this, apparently one is to enter exactly 511 characters >> >>>of input, then press the up arrow three times and wait - a core dump >> >>>follows. >> >> >>I know you didn't make the claim but you should first test it out before >> >>brandishing bull**** here. >> >> >>I've tried to reproduce the claimed results from your posted instruction >> >>and it does NOT produce a "core dump". >> >> > Hey don't shoot the messenger, people were interested in what was in >> > the presentation, I just relayed that information WITH THE CAVEAT THAT >> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for >> > an exploit, based on that I assumed it's genuine even if we haven't >> > been able to reproduce it. >> >> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha >> on which to try. It too failed to fail in any way. Curiously, I just >> happened to build an off-the-CD V8.3 Alpha only this morning in my >> workplace (just a pastime unfortunately) and intended to try it there >> and report tomorrow. Of course it could even be Alpha chip type >> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure >> but none-the-less real even if less-than adequately documented. The >> exploit might be more telling. Thanks for your ongoing reports. >> >> > I'm not trying to scaremonger or stir up ****, in fact I stated in my >> > original post that neither of these exploits seemed particularly earth >> > shattering. >> >> > Sampsa >> >> -- >> Every year is getting shorter never seem to find the time. >> Plans that either come to naught or half a page of scribbled lines >> Hanging on in quiet desperation is the English way >> The time is gone, the song is over, >> Thought I'd something more to say. >> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] > >$ sh sys >VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 >19:22:37 > > >$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >%DCL-W-TKNOVF, command element is too long - shorten That's not a "core dump" or any exploitable issue. That's merely an error message stating you have exceeded the acceptable command length. -- 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. |
|
#31
08-13-2008, 09:40 PM
|
| Re: DEFCON 16 and Hacking OpenVMS I tried on Alpha VMS 8.3 on the system account no less. From a DECterm window. 511 characters, no spaces. Up arrow 3 times, nothing special happened. |
|
#32
08-13-2008, 09:42 PM
|
| Re: DEFCON 16 and Hacking OpenVMS VAXman- @SendSpamHere.ORG wrote: > In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes: >>> I would have thought a CLI overflow to have been tried by at least a few >>> at DEFCON9 because the system automagically created service-rich user >>> accounts with of course DCL which the hackers were then free to abuse. >>> >>> We were not scrutinizing buffers however and any such overflow may in >>> our case have done nothing harmful (by luck or design). I think it was >>> version 7.1-? if it makes a difference. Did the gentleman specify any >>> versions? >> Default 8.3 install on an Alpha according to the presentation notes. >> To reproduce this, apparently one is to enter exactly 511 characters >> of input, then press the up arrow three times and wait - a core dump >> follows. > > I know you didn't make the claim but you should first test it out before > brandishing bull**** here. > > I've tried to reproduce the claimed results from your posted instruction > and it does NOT produce a "core dump". > This isn't entirely bull****. I reported it, case number AH800710. I saw the original post regarding the "execution of priviledged code" and was tempted to reply, but I didn't bother. However, I am now :-) The issue never allowed execution of priv. code (certainly not as far as I could see). The issue was simply a miss calculation in the RECALL ring buffer that resulted in an access violation. This seemed to coincide with the extension of the DCL command line buffer. Yes, the process does crash. Yes, it was a pain. However, it happened so infrequently and never actually did anything serious that I didn't report it for the first few months. The version of VMS is also incorrect. I reported the problem under OpenVMS Alpha V7.3-2 in June, 2004. Tim. |
|
#33
08-13-2008, 11:10 PM
|
| Re: DEFCON 16 and Hacking OpenVMS On Wed, Aug 13, 2008 at 9:42 PM, Tim E. Sneddon > VAXman- @SendSpamHere.ORG wrote: > >> In article < >> 9781c047-761a-4923-9aab-8c1a32ff7c67...oglegroups.com>, >> sampsal@gmail.com writes: >> >>> I would have thought a CLI overflow to have been tried by at least a few >>>> at DEFCON9 because the system automagically created service-rich user >>>> accounts with of course DCL which the hackers were then free to abuse. >>>> >>>> We were not scrutinizing buffers however and any such overflow may in >>>> our case have done nothing harmful (by luck or design). I think it was >>>> version 7.1-? if it makes a difference. Did the gentleman specify any >>>> versions? >>>> >>> Default 8.3 install on an Alpha according to the presentation notes. >>> To reproduce this, apparently one is to enter exactly 511 characters >>> of input, then press the up arrow three times and wait - a core dump >>> follows. >>> >> >> I know you didn't make the claim but you should first test it out before >> brandishing bull**** here. >> >> I've tried to reproduce the claimed results from your posted instruction >> and it does NOT produce a "core dump". >> > > This isn't entirely bull****. I reported it, case number AH800710. > > I saw the original post regarding the "execution of priviledged code" > and was tempted to reply, but I didn't bother. However, I am now :-) > > The issue never allowed execution of priv. code (certainly not as > far as I could see). The issue was simply a miss calculation in the > RECALL ring buffer that resulted in an access violation. This seemed > to coincide with the extension of the DCL command line buffer. Yes, > the process does crash. Yes, it was a pain. However, it happened so > infrequently and never actually did anything serious that I didn't > report it for the first few months. > > The version of VMS is also incorrect. I reported the problem under > OpenVMS Alpha V7.3-2 in June, 2004. > > Tim. Hi, Tim- Still got the Multia? Best regards, WWWebb |
|
#34
08-14-2008, 03:37 AM
|
| Re: DEFCON 16 and Hacking OpenVMS In article <00A7E113.29A29520@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes: >In article <995d1554-09f0-489d-904b-150a9ed48f83@t54g2000hsg.googlegroups.com>, jferraro >>On Aug 13, 9:17 am, Mark Daniel >>> samp...@gmail.com wrote: >>> >>>Default 8.3 install on an Alpha according to the presentation notes. >>> >>>To reproduce this, apparently one is to enter exactly 511 characters >>> >>>of input, then press the up arrow three times and wait - a core dump >>> >>>follows. >>> >>> >>I know you didn't make the claim but you should first test it out before >>> >>brandishing bull**** here. >>> >>> >>I've tried to reproduce the claimed results from your posted instruction >>> >>and it does NOT produce a "core dump". >>> >>> > Hey don't shoot the messenger, people were interested in what was in >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for >>> > an exploit, based on that I assumed it's genuine even if we haven't >>> > been able to reproduce it. >>> >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha >>> on which to try. It too failed to fail in any way. Curiously, I just >>> happened to build an off-the-CD V8.3 Alpha only this morning in my >>> workplace (just a pastime unfortunately) and intended to try it there >>> and report tomorrow. Of course it could even be Alpha chip type >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure >>> but none-the-less real even if less-than adequately documented. The >>> exploit might be more telling. Thanks for your ongoing reports. >>> >>> > I'm not trying to scaremonger or stir up ****, in fact I stated in my >>> > original post that neither of these exploits seemed particularly earth >>> > shattering. >>> >>> > Sampsa >>> >>> -- >>> Every year is getting shorter never seem to find the time. >>> Plans that either come to naught or half a page of scribbled lines >>> Hanging on in quiet desperation is the English way >>> The time is gone, the song is over, >>> Thought I'd something more to say. >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] >> >>$ sh sys >>VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 >>19:22:37 >> >> >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >>%DCL-W-TKNOVF, command element is too long - shorten > >That's not a "core dump" or any exploitable issue. That's merely an error >message stating you have exceeded the acceptable command length. > Plus you seem to be trying this out on a VAX 7.3x system when the reported problem is with Alpha VMS 8.3 " Default 8.3 install on an Alpha according to the presentation notes. To reproduce this, apparently one is to enter exactly 511 characters of input, then press the up arrow three times and wait - a core dump follows. " I believe the other problem which was reported which was with Finger was supposed to occur with VAX systems. David Webb Security team leader CCSS Middlesex University >-- >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. |
|
#35
08-14-2008, 07:17 AM
|
| Re: DEFCON 16 and Hacking OpenVMS On Aug 13, 9:22 pm, VAXman- @SendSpamHere.ORG wrote: > In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro > > > > >On Aug 13, 9:17 am, Mark Daniel > >> samp...@gmail.com wrote: > >> >>>Default 8.3 install on an Alpha according to the presentation notes. > >> >>>To reproduce this, apparently one is to enter exactly 511 characters > >> >>>of input, then press the up arrow three times and wait - a core dump > >> >>>follows. > > >> >>I know you didn't make the claim but you should first test it out before > >> >>brandishing bull**** here. > > >> >>I've tried to reproduce the claimed results from your posted instruction > >> >>and it does NOT produce a "core dump". > > >> > Hey don't shoot the messenger, people were interested in what was in > >> > the presentation, I just relayed that information WITH THE CAVEAT THAT > >> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > >> > an exploit, based on that I assumed it's genuine even if we haven't > >> > been able to reproduce it. > > >> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha > >> on which to try. It too failed to fail in any way. Curiously, I just > >> happened to build an off-the-CD V8.3 Alpha only this morning in my > >> workplace (just a pastime unfortunately) and intended to try it there > >> and report tomorrow. Of course it could even be Alpha chip type > >> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure > >> but none-the-less real even if less-than adequately documented. The > >> exploit might be more telling. Thanks for your ongoing reports. > > >> > I'm not trying to scaremonger or stir up ****, in fact I stated in my > >> > original post that neither of these exploits seemed particularly earth > >> > shattering. > > >> > Sampsa > > >> -- > >> Every year is getting shorter never seem to find the time. > >> Plans that either come to naught or half a page of scribbled lines > >> Hanging on in quiet desperation is the English way > >> The time is gone, the song is over, > >> Thought I'd something more to say. > >> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] > > >$ sh sys > >VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 > >19:22:37 > > > > >$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > >%DCL-W-TKNOVF, command element is too long - shorten > > That's not a "core dump" or any exploitable issue. That's merely an error > message stating you have exceeded the acceptable command length. > > -- > 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. Sorry... that was the point... its *not* a core-dump or exploitation... only posting to remove any doubts from those who may impose the theory on "older" openVMS instances... |
|
#36
08-14-2008, 07:50 AM
|
| Re: DEFCON 16 and Hacking OpenVMS In article >VAXman- @SendSpamHere.ORG wrote: >> In article <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, sampsal@gmail.com writes: >>>> I would have thought a CLI overflow to have been tried by at least a few >>>> at DEFCON9 because the system automagically created service-rich user >>>> accounts with of course DCL which the hackers were then free to abuse. >>>> >>>> We were not scrutinizing buffers however and any such overflow may in >>>> our case have done nothing harmful (by luck or design). I think it was >>>> version 7.1-? if it makes a difference. Did the gentleman specify any >>>> versions? >>> Default 8.3 install on an Alpha according to the presentation notes. >>> To reproduce this, apparently one is to enter exactly 511 characters >>> of input, then press the up arrow three times and wait - a core dump >>> follows. >> >> I know you didn't make the claim but you should first test it out before >> brandishing bull**** here. >> >> I've tried to reproduce the claimed results from your posted instruction >> and it does NOT produce a "core dump". >> > >This isn't entirely bull****. I reported it, case number AH800710. > >I saw the original post regarding the "execution of priviledged code" >and was tempted to reply, but I didn't bother. However, I am now :-) > >The issue never allowed execution of priv. code (certainly not as >far as I could see). The issue was simply a miss calculation in the >RECALL ring buffer that resulted in an access violation. This seemed >to coincide with the extension of the DCL command line buffer. Yes, >the process does crash. Yes, it was a pain. However, it happened so >infrequently and never actually did anything serious that I didn't >report it for the first few months. > >The version of VMS is also incorrect. I reported the problem under >OpenVMS Alpha V7.3-2 in June, 2004. I tried this "reproducer" on V7.3-2 too. Even if it does happen, I do not believe you could do much in terms of executing privileged code, especial- ly with DCL at supervisor mode. -- 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. |
|
#37
08-14-2008, 07:53 AM
|
| Re: DEFCON 16 and Hacking OpenVMS Tim E. Sneddon wrote: > VAXman- @SendSpamHere.ORG wrote: > >> In article >> <9781c047-761a-4923-9aab-8c1a32ff7c67@x35g2000hsb.googlegroups.com>, >> sampsal@gmail.com writes: >> >>>> I would have thought a CLI overflow to have been tried by at least a >>>> few >>>> at DEFCON9 because the system automagically created service-rich user >>>> accounts with of course DCL which the hackers were then free to abuse. >>>> >>>> We were not scrutinizing buffers however and any such overflow may in >>>> our case have done nothing harmful (by luck or design). I think it was >>>> version 7.1-? if it makes a difference. Did the gentleman specify any >>>> versions? >>> >>> Default 8.3 install on an Alpha according to the presentation notes. >>> To reproduce this, apparently one is to enter exactly 511 characters >>> of input, then press the up arrow three times and wait - a core dump >>> follows. >> >> >> I know you didn't make the claim but you should first test it out before >> brandishing bull**** here. >> >> I've tried to reproduce the claimed results from your posted instruction >> and it does NOT produce a "core dump". > > > This isn't entirely bull****. I reported it, case number AH800710. > > I saw the original post regarding the "execution of priviledged code" > and was tempted to reply, but I didn't bother. However, I am now :-) > > The issue never allowed execution of priv. code (certainly not as > far as I could see). The issue was simply a miss calculation in the > RECALL ring buffer that resulted in an access violation. This seemed > to coincide with the extension of the DCL command line buffer. Yes, > the process does crash. Yes, it was a pain. However, it happened so > infrequently and never actually did anything serious that I didn't > report it for the first few months. > > The version of VMS is also incorrect. I reported the problem under > OpenVMS Alpha V7.3-2 in June, 2004. Little point in me reporting that I couldn't produce anything resembling the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3 installation. This is a quoted-copy (to help circumvent wrapping) of that test: > $ product show hist > ------------------------------------ ----------- ----------- --- ----------- > PRODUCT KIT TYPE OPERATION VAL DATE > ------------------------------------ ----------- ----------- --- ----------- > CPQ AXPVMS CDSA V2.2-271 Full LP Install (C) 13-AUG-2008 > DEC AXPVMS DECNET_OSI V8.3 Full LP Install (C) 13-AUG-2008 > DEC AXPVMS DWMOTIF V1.6 Full LP Install (C) 13-AUG-2008 > DEC AXPVMS DWMOTIF_SUPPORT V8.3 Full LP Install (U) 13-AUG-2008 > DEC AXPVMS OPENVMS V8.3 Platform Install (U) 13-AUG-2008 > DEC AXPVMS TCPIP V5.6-9 Full LP Install (C) 13-AUG-2008 > DEC AXPVMS VMS V8.3 Oper System Install (U) 13-AUG-2008 > HP AXPVMS AVAIL_MAN_BASE V8.3 Full LP Install (U) 13-AUG-2008 > HP AXPVMS KERBEROS V3.0-103 Full LP Install (C) 13-AUG-2008 > HP AXPVMS SSL V1.3-281 Full LP Install (C) 13-AUG-2008 > HP AXPVMS TDC_RT V2.2-107 Full LP Install (C) 13-AUG-2008 > ------------------------------------ ----------- ----------- --- ----------- > 11 items found > > $ show cpu/full > > System: WASD, AlphaServer DS20 500 MHz > > SMP execlet = 3 : Disabled : Uniprocessing. > Config tree = None > Primary CPU = 0 > HWRPB CPUs = 2 > Page Size = 8192 > Revision Code = > Serial Number = S391400466 > Default CPU Capabilities: > System: QUORUM RUN > Default Process Capabilities: > System: QUORUM RUN > > CPU 0 State: RUN CPUDB: 81C18000 Handle: * None * > Process: FTA7:SYSTEM PID: 0000045C > Capabilities: > System: PRIMARY QUORUM RUN RAD0 > Slot Context: 84970180 > CPU - State..........: RC, PA, PP, CV, PV, PMV, PL > Type...........: EV6 (21264), Pass 2.3 > Speed..........: 500 Mhz > Variation......: VAX FP, IEEE FP, Primary Eligible > Serial Number..: > Revision.......: > Halt Request...: 0 > Software Comp..: 0.0 > PALCODE - Revision Code..: 1.98-01 > Compatibility..: 79 > Max Shared CPUs: 2 > Memory Space..: Physical = 00000000.00000000 Length = 0 > Scratch Space..: Physical = 00000000.00000000 Length = 0 > Bindings: * None * > Fastpath: > PKC0 > BG0 > Features: > Autostart - Enabled. > Fastpath - Selection enabled as Preferred CPU. > > $ typ test.com > $ write sys$output 79 * 6 + 37 > $ write sys$output f$fao("!79*A") > $ write sys$output f$fao("!79*B") > $ write sys$output f$fao("!79*C") > $ write sys$output f$fao("!79*D") > $ write sys$output f$fao("!79*E") > $ write sys$output f$fao("!79*F") > $ write sys$output f$fao("!37*G") > $ @test.com > 511 > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA > BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBB > CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCC > DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD DDDDDDDDDDDDDDDDDDDDDDDDDDDDD > EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEEEEEEEEEEEEEEE > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFF > GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG I then cut and paste the 511 characters (line-by-line) into the CLI and used the cursor keys to no result. > Tim. -- "And I am not frightened of dying, any time will do, I don't mind. Why should I be frightened of dying? There's no reason for it, you've gotta go sometime." "If you can hear this whispering you are dying." "I never said I was frightened of dying." [Wright; The Dark Side of the Moon] |
|
#38
08-14-2008, 09:23 AM
|
| Re: DEFCON 16 and Hacking OpenVMS Mark Daniel wrote: > Little point in me reporting that I couldn't produce anything resembling > the (albeit sketchy) description of the 'exploit' on my off-the-CD V8.3 > installation. This is a quoted-copy (to help circumvent wrapping) of > that test: > [...snip...] > I then cut and paste the 511 characters (line-by-line) into the CLI and > used the cursor keys to no result. > I did some looking around through old emails and came across the reproducer (below). I believe it is what the regression test uses. Apologies as this will probably wrap. I might also add that this bug was fixed in VMS732_DCL-V0200. $ CREATE RECALL_TEST_02.TXT directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;% directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;% directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;% directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;1 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;2 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;3 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;4 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;5 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;6 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;7 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;8 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;9 directory/date=create/output=NL:/PROTEC/SINCE DISK$REGRES:[VERIFICATION.DCl]RECALL_BUFFER.TEST;% directory/date=create/output=NL:/PROTEC/SINC $ RECALL/ERASE $ RECALL/INPUT=RECALL_TEST_02.TXT $ REACLL/ALL If this test doesn't crash your process you will at least get some very "odd" results from the RECALL list. Tim. |
|
#39
08-14-2008, 09:43 AM
|
| Re: DEFCON 16 and Hacking OpenVMS On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote: > In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes: > >In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro > >>On Aug 13, 9:17 am, Mark Daniel > >>> samp...@gmail.com wrote: > >>> >>>Default 8.3 install on an Alpha according to the presentation notes. > >>> >>>To reproduce this, apparently one is to enter exactly 511 characters > >>> >>>of input, then press the up arrow three times and wait - a core dump > >>> >>>follows. > > >>> >>I know you didn't make the claim but you should first test it out before > >>> >>brandishing bull**** here. > > >>> >>I've tried to reproduce the claimed results from your posted instruction > >>> >>and it does NOT produce a "core dump". > > >>> > Hey don't shoot the messenger, people were interested in what was in > >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT > >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for > >>> > an exploit, based on that I assumed it's genuine even if we haven't > >>> > been able to reproduce it. > > >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha > >>> on which to try. It too failed to fail in any way. Curiously, I just > >>> happened to build an off-the-CD V8.3 Alpha only this morning in my > >>> workplace (just a pastime unfortunately) and intended to try it there > >>> and report tomorrow. Of course it could even be Alpha chip type > >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure > >>> but none-the-less real even if less-than adequately documented. The > >>> exploit might be more telling. Thanks for your ongoing reports. > > >>> > I'm not trying to scaremonger or stir up ****, in fact I stated in my > >>> > original post that neither of these exploits seemed particularly earth > >>> > shattering. > > >>> > Sampsa > > >>> -- > >>> Every year is getting shorter never seem to find the time. > >>> Plans that either come to naught or half a page of scribbled lines > >>> Hanging on in quiet desperation is the English way > >>> The time is gone, the song is over, > >>> Thought I'd something more to say. > >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] > > >>$ sh sys > >>VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 > >>19:22:37 > >> > > >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- > >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > >>%DCL-W-TKNOVF, command element is too long - shorten > > >That's not a "core dump" or any exploitable issue. That's merely an error > >message stating you have exceeded the acceptable command length. > > Plus you seem to be trying this out on a VAX 7.3x system when the reported > problem is with Alpha VMS 8.3 > > " > Default 8.3 install on an Alpha according to the presentation notes. > To reproduce this, apparently one is to enter exactly 511 characters > of input, then press the up arrow three times and wait - a core dump > follows. > " > I believe the other problem which was reported which was with Finger > was supposed to occur with VAX systems. > > David Webb > Security team leader > CCSS > Middlesex University > > >-- > >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. David, A "core dump"? I hate to be a bit of a pedant, but do you mean "end of users process and logout" or "system crash". Frankly, a "bug" that causes a user to terminate his own process (which can be done in any number of intended ways) is not a true security vulnerability. A security vulnerability needs to affect other users or the system as a whole. "Suicide" is far different from "murder". - Bob Gezelter, http://www.rlgsc.com |
|
#40
08-14-2008, 10:18 AM
|
| Re: DEFCON 16 and Hacking OpenVMS In article >On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote: >> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes: >> >In article <995d1554-09f0-489d-904b-150a9ed48...@t54g2000hsg.googlegroups.com>, jferraro >> >>On Aug 13, 9:17 am, Mark Daniel >> >>> samp...@gmail.com wrote: >> >>> >>>Default 8.3 install on an Alpha according to the presentation notes. >> >>> >>>To reproduce this, apparently one is to enter exactly 511 characters >> >>> >>>of input, then press the up arrow three times and wait - a core dump >> >>> >>>follows. >> >> >>> >>I know you didn't make the claim but you should first test it out before >> >>> >>brandishing bull**** here. >> >> >>> >>I've tried to reproduce the claimed results from your posted instruction >> >>> >>and it does NOT produce a "core dump". >> >> >>> > Hey don't shoot the messenger, people were interested in what was in >> >>> > the presentation, I just relayed that information WITH THE CAVEAT THAT >> >>> > I DIDN'T TEST IT. They had screenshots of the flaw and source code for >> >>> > an exploit, based on that I assumed it's genuine even if we haven't >> >>> > been able to reproduce it. >> >> >>> I too cannot reproduce it but this evening have only an ECOed V8.3 Alpha >> >>> on which to try. It too failed to fail in any way. Curiously, I just >> >>> happened to build an off-the-CD V8.3 Alpha only this morning in my >> >>> workplace (just a pastime unfortunately) and intended to try it there >> >>> and report tomorrow. Of course it could even be Alpha chip type >> >>> -specific (fail on an EV56 but not an EV67, etc.) making it more obscure >> >>> but none-the-less real even if less-than adequately documented. The >> >>> exploit might be more telling. Thanks for your ongoing reports. >> >> >>> > I'm not trying to scaremonger or stir up ****, in fact I stated in my >> >>> > original post that neither of these exploits seemed particularly earth >> >>> > shattering. >> >> >>> > Sampsa >> >> >>> -- >> >>> Every year is getting shorter never seem to find the time. >> >>> Plans that either come to naught or half a page of scribbled lines >> >>> Hanging on in quiet desperation is the English way >> >>> The time is gone, the song is over, >> >>> Thought I'd something more to say. >> >>> [Mason, Waters, Wright, Gilmour; The Dark Side of the Moon] >> >> >>$ sh sys >> >>VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372 >> >>19:22:37 >> >> >> >> >>$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa- >> >>_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >> >>%DCL-W-TKNOVF, command element is too long - shorten >> >> >That's not a "core dump" or any exploitable issue. That's merely an error >> >message stating you have exceeded the acceptable command length. >> >> Plus you seem to be trying this out on a VAX 7.3x system when the reported >> problem is with Alpha VMS 8.3 >> >> " >> Default 8.3 install on an Alpha according to the presentation notes. >> To reproduce this, apparently one is to enter exactly 511 characters >> of input, then press the up arrow three times and wait - a core dump >> follows. >> " >> I believe the other problem which was reported which was with Finger >> was supposed to occur with VAX systems. >> >> David Webb >> Security team leader >> CCSS >> Middlesex University >> >> >-- >> >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. > >David, > >A "core dump"? I hate to be a bit of a pedant, but do you mean "end of >users process and logout" or "system crash". > >Frankly, a "bug" that causes a user to terminate his own process >(which can be done in any number of intended ways) is not a true >security vulnerability. A security vulnerability needs to affect >other users or the system as a whole. > >"Suicide" is far different from "murder". > Bob, your asking the wrong person. I and a number of others are just responding to Sampsa's report of VMS vulnerabilities in the Defcon 16 slides. The initial report from Sampsa said about this bug " 2. A CLI buffer overflow on Alphas. Basically any input over 511 characters causes an overflow, it seems to be possible to have a privileged process execute arbitrary code. " David Webb Security team leader CCSS Middlesex University >- Bob Gezelter, http://www.rlgsc.com |
