DEFCON 16 and Hacking OpenVMS
Mark Daniel
is due to be presented this Sunday, Aug 10th 2008
Does anyone know ...
o whether there will be anyone from the VMS community at this event;
o the content of this presentation;
o whether the 'proceedings' will be published?
The abstract is protraying the potential exploits as novel and so would
make an interesting read.
--
Ticking away the moments that make up a dull day
You fritter and waste the hours in an offhand way.
Kicking around on a piece of ground in your home town
Waiting for someone or something to show you the way.
[Mason, Waters, Wright, Gilmour; The Dark Side of the Moon]
bradhamilton
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>
> is due to be presented this Sunday, Aug 10th 2008
>
> Does anyone know ...
>
> o whether there will be anyone from the VMS community at this event;
>
> o the content of this presentation;
>
> o whether the 'proceedings' will be published?
>
> The abstract is protraying the potential exploits as novel and so would
> make an interesting read.
You might want to ask the question over at the Deathrow cluster - there
are likely to be some attendees from that group.
Mark Daniel
I could also post on the relevant ITRC forum but VMS vulnerabilities
likely would be considered off-topic and it end up expunged!
--
Tired of lying in the sunshine staying home to watch the rain.
You are young and life is long and there is time to kill today.
And then one day you find ten years have got behind you.
No one told you when to run, you missed the starting gun.
sam...@gmail.com
Mark Daniel
> There's apparently an overflow flat in Multinet's Fingerd as well:
>
> http://seclists.org/bugtraq/2008/Aug/0056.html
This appears to behave as described on at least VAX VMS V7.3 MultiNet
V5.1 Rev A-X but not on Alpha VMS V8.3 V5.2 Rev A-X or I64 VMS V8.3 V5.2
Rev A-X (three platforms I have access to).
$ echo `perl -e 'print "a"x1000'` | nc -v host.name 79
Connection to host.name 79 port [tcp/finger] succeeded!
I guess we can assume the 'group of lads' would be keeping an occasional
eye on c.o.v. :-)
--
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
William Webb
WWWebb
bradhamilton
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>
> is due to be presented this Sunday, Aug 10th 2008
>
> Does anyone know ...
>
> o whether there will be anyone from the VMS community at this event;
>
> o the content of this presentation;
>
> o whether the 'proceedings' will be published?
>
> The abstract is protraying the potential exploits as novel and so would
> make an interesting read.
I will wait for this weekend, like some of us, but in the meantime, I
will note that one of the presenters claims to have an interest in
"social engineering". Of course, the abstract promises "0day
vulnerabilities", but we will have to wait and see.
Bob Koehler
>
> The last "black hat" stuff I read (and it was a while ago) was quite
> outdated and went back to the days when SYSTEM, FIELD, etc had default
> passwords set at installation time.
>
> That's no longer the case, and has been for some time.
There's a fairly easy to find (or it was last time I bothered
looking) guide to hacking VMS that I think you're talking about.
It was written to a default installation and bad system management
prior to VMS 5.0. It used the canned passwords to get access to
a privileged account. It told of all kinds of little things a
privileged account could do.
Unless the DEFCON sessions reports ways to access a system without
authorization, or elevate your privileges to a higher class without
authorization, on a properly installed and managed system, it's just
smoke up your virtual skirt.
We wait to see.
Simon Clubley
> http://www.defcon.org/html/defcon-16/dc-16-speakers.html#Oberg
>
> is due to be presented this Sunday, Aug 10th 2008
>
Does anyone know what happened with this ?
Thanks,
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
patrick jankowiak
handily by OpenVMS on Alpha courtesy of The Wiz, Coremac, and Opcom; the
legend of which is chronicled here:
http://www.bunkerofdoom.com/defcon/defcon9.html
-or maybe they forgot about it and this is completely new.
The rules of the 'game' were changed forever. But never mind;
By the time I saw it, it was too late to get in the truck and drive to
the DEFCON by myself.
Patrick J.
patrick jankowiak
http://www.openvms.org/stories.php?story=07/05/18/5543122
just to pass some time till someone can report.
William Webb
WWWebb
patrick jankowiak
Hi William,
Thank you and I guess I need to show up to the party from time to time.
I guess I sort of navigated past the edge of the known world, and found
more worlds and adventures to explore.
sam...@gmail.com
I just finished reading the presenation slides from DEFCON and
fortunately it doesn't to be anything earth-shattering, two exploits
are described:
1. A format string vulnerability in the FINGER client (VAX only). The
example shellcode is stored on a remote system's .plan file and forces
the victim FINGER client to modify SYSUAF.
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.
Anyway, this is from a 10 minute reading of the slides, I might have
missed something, but the important thing (IMHO) is that neither of
these exploits are possible from remote but require a malicious user
to already have an account on the targeted system.
Sampsa
dav...@alpha2.mdx.ac.uk
>Guys,
>
>I just finished reading the presenation slides from DEFCON and
>fortunately it doesn't to be anything earth-shattering, two exploits
>are described:
>
>1. A format string vulnerability in the FINGER client (VAX only). The
>example shellcode is stored on a remote system's .plan file and forces
>the victim FINGER client to modify SYSUAF.
>
Is this with DEC TCPIP services or is it something to do with the
Multinet finger vulnerability ?
see
http://www.multinet.process.com/scripts/eco/eco_tlb.com?FINGER-010_A052
>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.
>
Can you explain this one in a bit more detail ?
Is this an attack against DCL itself, images installed with privileges
or something else ?
David Webb
Security team leader
CCSS
Middlesex University
sam...@gmail.com
> >1. A format string vulnerability in the FINGER client (VAX only). The
> >example shellcode is stored on a remote system's .plan file and forces
> >the victim FINGER client to modify SYSUAF.
>
> Is this with DEC TCPIP services or is it something to do with the
> Multinet finger vulnerability ?
It appears to be something separate, since it seems to have to do with
a format string
vulnerability. Basically someone puts a bunch of % strings and
shellcode in their .plan
on a remote host, fingers that user from the target host, and the
FINGER client executes
the shellcode due to the format string vulnerability in the client.
> >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.
>
> Can you explain this one in a bit more detail ?
> Is this an attack against DCL itself, images installed with privileges
> or something else ?
I think this might be a DCL issue, it seems to work across a number of
different images. Not had a chance to play with this as my own VMS
box is down at the moment.
Sampsa
Bob Koehler
> example shellcode is stored on a remote system's .plan file and forces
> the victim FINGER client to modify SYSUAF.
Do they say which finger client? HPs?
Bob Koehler
>
> I just finished reading the presenation slides from DEFCON and
> fortunately it doesn't to be anything earth-shattering, two exploits
> are described:
Are these publically available? (If there is anything in them, I'd
like to review my systems).
sam...@gmail.com
Koehler) wrote:
> In article <6419afac-bb99-4d7d-b61c-2e29234df...@z72g2000hsb.googlegroups.com>, samp...@gmail.com writes:
>
> > Guys,
>
> > I just finished reading the presenation slides from DEFCON and
> > fortunately it doesn't to be anything earth-shattering, two exploits
> > are described:
>
> Are these publically available? (If there is anything in them, I'd
> like to review my systems).
I got them from a friend who's colleague was at DEFCON - I don't know
what the distribution/copyright issues are with the document so I
daren't host them on my web page.
Sampsa
patrick jankowiak
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?
Patrick J
sam...@gmail.com
> 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
bradhamilton
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.
VAXman-
>> 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?
>
>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 bullshit 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.
sam...@gmail.com
> >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 bullshit 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 shit, in fact I stated in my
original post that neither of these exploits seemed particularly earth
shattering.
Sampsa
William Webb
Mark Daniel
>>>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 bullshit 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 shit, 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.
jferraro
$ sh sys
VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372
19:22:37
<truncate..>
$ define test$logical aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-
_$ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
%DCL-W-TKNOVF, command element is too long - shorten
jferraro
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
\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\
$
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
Tom Linden
> $ 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
VAXman-
>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>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
That's not a "core dump" or any exploitable issue. That's merely an error
message stating you have exceeded the acceptable command length.
JF Mezei
window.
511 characters, no spaces. Up arrow 3 times, nothing special happened.
Tim E. Sneddon
> In article <9781c047-761a-4923...@x35g2000hsb.googlegroups.com>, sam...@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 bullshit 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 bullshit. 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.
William Webb
dav...@alpha2.mdx.ac.uk
>In article <995d1554-09f0-489d...@t54g2000hsg.googlegroups.com>, jferraro <jfer...@gmail.com> writes:
>>On Aug 13, 9:17 am, Mark Daniel <mark.dan...@vsm.com.au> wrote:
>>VMS/VAX V7.3-2 on node WOPR 13-AUG-2008 19:00:07.39 Uptime 372
>>19:22:37
>><truncate..>
>>
>>$ 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.
>
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
jferraro
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...
VAXman-
>VAXman- @SendSpamHere.ORG wrote:
>> In article <9781c047-761a-4923...@x35g2000hsb.googlegroups.com>, sam...@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 bullshit here.
>>
>> I've tried to reproduce the claimed results from your posted instruction
>> and it does NOT produce a "core dump".
>>
>
>
>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.
Mark Daniel
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
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
> CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
> DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> 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]
Tim E. Sneddon
> 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.
Bob Gezelter
> In article <00A7E113.29A29...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
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
dav...@alpha2.mdx.ac.uk
>On Aug 14, 3:37 am, davi...@alpha2.mdx.ac.uk wrote:
>
>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".
>
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
Bob Gezelter
David,
My apologies, I apparently clicked on the incorrect entry. I meant the
question for Tim Sneddon.
Tim E. Sneddon
> David,
>
> My apologies, I apparently clicked on the incorrect entry. I meant the
> question for Tim Sneddon.
>
You'll have to check the quoting again :-) I never said it was
a "core dump". I also said that the problem *didn't* allow the
execution of arbitrary code at priviledge. I just said it was a
pain. I tend to use my up arrow quite a bit. It is annoying
when the process disappears randomly. It's certainly not a
security hole and I never claimed as such. David Webb got it
right when he said people were responding to Sampsa's report.
From what I have read Sampsa was merely passing along the work
of others at the request of readers of this newsgroup.
As I said, I wasn't even going to reply to it. The alleged
vulnerability was clearly mis-reported crap. However, when everyone
jumped on it and it turned into a big thing I decided to clear
it up. I even went and dug out the details of the regression
test and the case number, so we could finally put this thing
to rest :-)
Tim.
VAXman-
>Bob Gezelter wrote:
>> David,
>>
>> My apologies, I apparently clicked on the incorrect entry. I meant the
>> question for Tim Sneddon.
>>
>
>a "core dump". I also said that the problem *didn't* allow the
>execution of arbitrary code at priviledge. I just said it was a
>pain. I tend to use my up arrow quite a bit. It is annoying
>when the process disappears randomly. It's certainly not a
>security hole and I never claimed as such. David Webb got it
>right when he said people were responding to Sampsa's report.
> From what I have read Sampsa was merely passing along the work
>of others at the request of readers of this newsgroup.
>
>As I said, I wasn't even going to reply to it. The alleged
>vulnerability was clearly mis-reported crap. However, when everyone
>jumped on it and it turned into a big thing I decided to clear
>it up. I even went and dug out the details of the regression
>test and the case number, so we could finally put this thing
>to rest :-)
Thanks for the test. I'll try it later. However, I would like to see
these "hacker" slides from the DEFcon. Are they available for general
consumption anywhere on the net?
Tim E. Sneddon
> Thanks for the test. I'll try it later. However, I would like to see
> these "hacker" slides from the DEFcon. Are they available for general
> consumption anywhere on the net?
>
Beats me. Sampsa seems to be the source for those.
Tim.
dav...@alpha2.mdx.ac.uk
>VAXman- @SendSpamHere.ORG wrote:
>> Thanks for the test. I'll try it later. However, I would like to see
>> these "hacker" slides from the DEFcon. Are they available for general
>> consumption anywhere on the net?
>>
>
>
>Tim.
Hopefully they will be at some point but for the moment we are
reliant for information on Sampsa who said in a previous post
"
I got them from a friend who's colleague was at DEFCON - I don't know
what the distribution/copyright issues are with the document so I daren't
host them on my webpage.
Bob Gezelter
Tim,
Thank you for the first hand data.
As the late Richard Feynman reported in "Surely You Joking Mr.
Feynman", reports citing reports citing reports are unreliable (which
is the underlying for the hearsay rules in legal procedures).
If we can confirm that the details, perhaps someone should publish the
facts (I will do so, if someone can get me the original DEFCON
presentation so that I can see what it is).
Richard B. Gilbert
Well, that last line is likely the produce an unwanted result!
Richard B. Gilbert
In either case the results are similar; a dead body!!
bu...@signedness.org
> VAXman- @SendSpamHere.ORG wrote:
I googled the case number but didn't find anything except this thread,
so I'm not 100% sure what it refers to. But not entirely bullshit and
never exploitable? Well if you are talking about our bugs then you may
want to watch these videos:
http://www.signedness.org/misc/openvms_local_install_exploit.avi
http://www.signedness.org/misc/openvms_local_tcpip_exploit.avi
http://www.signedness.org/misc/openvms_local_telnet_exploit.avi
Can't be bothered to upload the finger video atm, and its easy enough
to reproduce. Just fingering a users whose .plan file contains %n%n%n%n
%n%n%n or something similar should do it. and while I'm on the topic
of the finger exploit, there seem to be some confusion about it. We
exploited it on VAX but Alpha is vulnerable too (and I'm guessing
Itanium too but not verified). The command line bug may or may not be
exploitable on VAX (too jet lagged to go into that atm)
PS. There are many many many more things to be explored / exploited
for those interested in OpenVMS security.. But there is only so much
you can fit into 50mins..
Cheers,
signedness.org
bradhamilton
[...]
> Well if you are talking about our bugs then you may
> want to watch these videos:
>
> http://www.signedness.org/misc/openvms_local_install_exploit.avi
> http://www.signedness.org/misc/openvms_local_tcpip_exploit.avi
> http://www.signedness.org/misc/openvms_local_telnet_exploit.avi
>
There is no sound on the videos. I can't reproduce these "exploits"
because I don't have access to FILE.EXE.
> Can't be bothered to upload the finger video atm, and its easy enough
> to reproduce. Just fingering a users whose .plan file contains %n%n%n%n
> %n%n%n or something similar should do it.
Like this (on an Alpha)?
brad@coyote:~$ finger br...@xxx.xxx.xxx
[xxx.xxx.xxx]
BRAD brad 20A18427 *DCL* FTA1680ssh/x.x.x.x.
Plan:
mangiD kcirtaP
regnaD kciN
Humphrey Chimpden Earwicker
Anna Livia Plurabelle
%n%n%n%n%n%n%n
Sorry, I'm not impressed, at least not without more detail than has been
provided so far.
VAXman-
>On Aug 14, 2:42=A0am, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>ps.com>, samp...@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
>..
>>
>> >>> We were not scrutinizing buffers however and any such overflow may in
>s
>> >>> 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.
>>
>e
>> > brandishing bullshit here.
>>
>> > I've tried to reproduce the claimed results from your posted instructio=
>n
>> > and it does NOT produce a "core dump".
>>
>> This isn't entirely bullshit. 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.
>
>
>so I'm not 100% sure what it refers to. But not entirely bullshit and
>want to watch these videos:
>
>http://www.signedness.org/misc/openvms_local_install_exploit.avi
>http://www.signedness.org/misc/openvms_local_tcpip_exploit.avi
>http://www.signedness.org/misc/openvms_local_telnet_exploit.avi
Videos of several minutes of black and silence.
--
Tim E. Sneddon
It refers to the HP case number. I merely offered it as proof that
I logged the job and that it closed with a successful result.
Does anybody bother actually reading what I posted or are they so
busy with their heads up their arses that they seem to miss the
finer points?
I don't care about the finger exploit. I don't care about the videos.
There was a claim that this bug in the RECALL code would allow one
to run arbitrary priv. code. I know first hand that it doesn't. Why?
Because I'm the guy who found it. It lets you crash your process,
when you're at DCL! Holy shit, stop the press! It's an exploit!
I don't think so. As Bob Gezelter pointed out. There are plenty of
other ways to kill your process from DCL. It is *not* a security
vulnerability. It certainly was an annoying bug though.
Tim.
bu...@signedness.org
LOL
The bug is not in DCL, and if you care to watch the videos you will
see that an arbitrary program can be run with higher privileges.
As an example we wrote FILE.EXE (since we can not get any output to
the terminal from 'show proc/priv' when exploiting) which simply
writes the privileges of the current process to PRIVS.TXT.
We first execute FILE.EXE from the shell to show that the user has the
default privileges.
FILE.EXE is then executed with higher privileges from the program that
we are exploiting (install, tcpip and telnet, but there are others as
well).
Oh, and you need the vmware codecs installed to watch the videos.
Cheers,
signedness.org
bradhamilton
[...]
>
> LOL
> The bug is not in DCL, and if you care to watch the videos you will
> see that an arbitrary program can be run with higher privileges.
> As an example we wrote FILE.EXE (since we can not get any output to
> the terminal from 'show proc/priv' when exploiting) which simply
> writes the privileges of the current process to PRIVS.TXT.
> We first execute FILE.EXE from the shell to show that the user has the
> default privileges.
> FILE.EXE is then executed with higher privileges from the program that
> we are exploiting (install, tcpip and telnet, but there are others as
> well).
>
> Oh, and you need the vmware codecs installed to watch the videos.
>
> Cheers,
> signedness.org
Thanks for the additional information. I was curious as to why you ran
FILE.EXE, as opposed to a simple "show proc/priv" before and after your
exploit.
I can see that you have gained privilege after the "exploit", but the
"exploit" itself seems to be another EXE (SHELLCODE?) itself. Why all
the "mystery"? Without the source code, we can't "see" what's going on,
and reproduce it ourselves; we are left to trusting that you are not
playing some kind of bizarre, behind-the-scenes tricks to pretend that
you are elevating privileges. Sorry to be so mistrustful, but that's
just a common attitude here.
I was able to "view" the videos on a linux laptop using "Movie Player".
I tried to view the videos on an XP box, but both Media Player and
Quicktime show dark screens, as reported by Brian. Media player claims
that a codec is corrupt (I assume that this is the vmware codec referred
to above).
As for the finger "exploit", can you be more specific? As I've shown,
seven "%n" in my plan file is not enough to trigger bizarre, unwanted
behavior.
Tim E. Sneddon
I've got them and watched the local telnet exploit (I'll check out the
others later). I'm interested, I'd like to know more. So where is the
code used to generate those results and how come you don't use SHOW
PROCESS and INSTALL to show privs?
Tim.
patrick jankowiak
Forgive me, but all this "enter exactly 511 characters and press the up
arrow three times" business reminds me of the old Dick Van Dyke episode
schtick that started with a telephone call and ended with "..then swing
the bag over your head and scream like a chicken"
Vaxman -please e-mail me your shipment receiving address.. I am a couple
years remiss in sending you something.
Patrick J
bu...@signedness.org
We are not going to release the exploits for some time.. Seven "%n"
should be more than enough to hit something you cant write to and
crash the finger client (provided that HP has not patched it, we have
not heard from them in weeks even though we asked for updates)
System service numbers seems to move around between releases (like
windows system calls), since all our payloads assumes 8.3 (alpha) and
7.3 (vax) it would probably just mean that we get another bunch of
replies saying "it only crashes the binary and won't get "SYSTEM"".
Another thing is that at least the VAX shellcode was written purely
for demo purposes and got my username hardcoded into it (uses a system
service to enable all privs on my account)
If anybody is in or around London I'd be happy to settle whether or
not we are bullshitting with a live demo at a dc4420 meeting or
similar event..
The alpha exploits uses the sys$creprc system service to execute the
file FILE.EXE that happens to show the privs of the process. The
reason we took that route instead of spawning a new "shell" with
higher privs is that it was easier to test/debug.
btw for those of you who doubt us, check this out
http://www.securityfocus.com/archive/1/495207 either we set a new
trend making it fashionable to bullshit about OpenVMS bugs or maybe it
is possible that VMS is pretty exploitable.. ;)
patrick jankowiak
I'm running that version on the Alpha out in the lab. I used a
privileged acct. and I am using a 132 column terminal width. (never mind
the system time, I just did this now.)
$ show sys
OpenVMS V7.3-2 on node WIZ 16-DEC-2005 11:52:17.01 Uptime 29 02:28:59
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
up three times, and down three times, nothing.. but this shows now:
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
Nothing more.. so finally I ran the up arrow till all the commands were
gone, and held it a bit, then down arrow till the same, holding it a bit
as well, and did this a few times and got this:
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
$
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
$
%RMS-F-RER, file read error
-SYSTEM-W-DATAOVERUN, data overrun
$
It did not trash my (telnet) session, and after pressing the up arrow
lots of times (which did nothing but replace the line above with the
previous line as shown by the $ signs interspersed) I started pressing
the down arrow (reversing the process), then it apparently got pissed
off as shown.
I do not have the resources to know what really happened or where, if
anywhere besides the bit bucket, the overrun went. I assume into the
bottomless pit where all naughty VMS user keystrokes go..
But all I have likely done is confirm the previously reported Miss
Calculation of June 2004.
Patrick
patrick jankowiak
seemingly intricate or repetitive method is involved.
Patrick
R.A.Omond
> [...snip...]
> Can't be bothered to upload the finger video atm, and its easy enough
> to reproduce. Just fingering a users whose .plan file contains %n%n%n%n
> %n%n%n or something similar should do it. and while I'm on the topic
> of the finger exploit, there seem to be some confusion about it. We
> exploited it on VAX but Alpha is vulnerable too (and I'm guessing
> Itanium too but not verified). The command line bug may or may not be
> exploitable on VAX (too jet lagged to go into that atm)
Hmmm... looks like there's something in this.
Wizard» show sys/noproc
OpenVMS V8.3 on node WIZARD 15-AUG-2008 09:05:07.62
Wizard» type .plan
%n
Wizard» finger roy
Login name: ROY In real life: Roy Omond
Account: SYSTEM Directory: $U:[ROY]
Last login: Wed 13-AUG-2008 10:43:45
No unread mail
Access violation, reason mask=04,
virtual address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000000000
FFFFFFFF80BA3BA4
000000000000001B
Register dump:
R0 = 0000000000000000 R1 = 0000000000000049
R2 = 000000007BEEDCD0
R3 = 000000007AE48940 R4 = 0000000000000000
R5 = 0000000000000000
R6 = 000000007AE48928 R7 = FFFFFFFFFFFFFFFF
R8 = 000000007BF628E8
R9 = 0000000000050011 R10 = 00000000000202D0
R11 = 0000000000000000
R12 = 0000000000116C88 R13 = 0000000000000000
R14 = 0000000000000052
R15 = 0000000000116BC8 R16 = 0000000000050011
R17 = 000000007AE48DB0
R18 = 000000007AE48DB0 R19 = 000000007AE48930
R20 = 0000000000000008
R21 = 0000000000000000 R22 = 0000000000000000
R23 = 0000000000000000
R24 = 0000000000000000 R25 = FFFFFFFFFFFFEC96
R26 = 0000000000000001
R27 = FFFFFFFF80BA36D0 R28 = FFFFFFFF80BA3B30
R29 = 000000007AE48880
SP = 000000007AE48880 PC = FFFFFFFF80BA3BA4
PS = 000000000000001B
Same behaviour for any number of "%n" strings.
sam...@gmail.com
$ show sys/noproc
OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:20.73 Uptime 0
23:14:17
$ type .plan
%n
$ show sys/noproc
OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:25.34 Uptime 0
23:14:21
$ finger sampsa
Login name: SAMPSA In real life: SAMPSA LAINE
Account: SAMPSA Directory: SYS$SYSDEVICE:
[SAMPSA]
Last login: Fri 15-AUG-2008 09:26:39
No unread mail
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000004
0000000000000000
FFFFFFFF80BA3BA4
000000000000001B
Register dump:
R0 = 0000000000000000 R1 = 0000000000000049 R2 =
000000007BEEDCD0
R3 = 000000007AE26940 R4 = 0000000000000000 R5 =
0000000000000000
R6 = 000000007AE26928 R7 = FFFFFFFFFFFFFFFF R8 =
000000007BF628E8
R9 = 0000000000050011 R10 = 00000000000202D0 R11 =
0000000000000000
R12 = 0000000000116C88 R13 = 0000000000000000 R14 =
0000000000000053
R15 = 0000000000116BC8 R16 = 0000000000050011 R17 =
000000007AE26DB0
R18 = 000000007AE26DB0 R19 = 000000007AE26930 R20 =
0000000000000008
R21 = 0000000000000000 R22 = 0000000000000000 R23 =
0000000000000000
R24 = 0000000000000000 R25 = FFFFFFFFFFFFEC96 R26 =
0000000000000001
R27 = FFFFFFFF80BA36D0 R28 = FFFFFFFF80BA3B30 R29 =
000000007AE26880
SP = 000000007AE26880 PC = FFFFFFFF80BA3BA4 PS =
000000000000001B
bradhamilton
> Verified (finally got my VMS box up):
>
> $ show sys/noproc
> OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:20.73 Uptime 0
> 23:14:17
> $ type .plan
> %n
> $ show sys/noproc
> OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:25.34 Uptime 0
> 23:14:21
> $ finger sampsa
> Login name: SAMPSA In real life: SAMPSA LAINE
> Account: SAMPSA Directory: SYS$SYSDEVICE:
> [SAMPSA]
> Last login: Fri 15-AUG-2008 09:26:39
> No unread mail
> %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
> address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B
OK, now *please*, someone show us how to "properly" format the .plan
(plan.txt) file to produce this result.
:-)
[...]
Graham Burley
>OK, now *please*, someone show us how to "properly" format the .plan
>(plan.txt) file to produce this result.
And which finger (TCP/IP Services, Multinet, ...)
VAXman-
>{...snip...}
>LOL
>The bug is not in DCL, and if you care to watch the videos you will
>see that an arbitrary program can be run with higher privileges.
>As an example we wrote FILE.EXE (since we can not get any output to
>the terminal from 'show proc/priv' when exploiting) which simply
WHy not?
>writes the privileges of the current process to PRIVS.TXT.
>We first execute FILE.EXE from the shell to show that the user has the
>default privileges.
>FILE.EXE is then executed with higher privileges from the program that
>we are exploiting (install, tcpip and telnet, but there are others as
>well).
>
>Oh, and you need the vmware codecs installed to watch the videos.
Why not .MPG which doesn't require the download of some questionable
software from some site on the internet?
VAXman-
VLC gives be a white screen with [cmn@fc6 ~]$ , and then runs for 1:06
with nothing else.
VAXman-
>
>Forgive me, but all this "enter exactly 511 characters and press the up
>schtick that started with a telephone call and ended with "..then swing
>the bag over your head and scream like a chicken"
ROFL!
>Vaxman -please e-mail me your shipment receiving address.. I am a couple
>years remiss in sending you something.
A rack of DTC03s?
Address forthcoming in separate email.
bu...@signedness.org
> Mark Daniel wrote:
> > Tim E. Sneddon wrote:
> >> VAXman- @SendSpamHere.ORG wrote:
>
> >>> In article
>
> read more »
You have all the information that you need to reproduce this
vulnerability on a vulnerable system.
If you watch the video you can see that the bug is triggered from the
prompt of the vulnerable program (like for example INSTALL>).
bu...@signedness.org
> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
> >LOL
> >The bug is not in DCL, and if you care to watch the videos you will
> >see that an arbitrary program can be run with higher privileges.
> >As an example we wrote FILE.EXE (since we can not get any output to
>
> __________________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>the terminal from 'show proc/priv' when exploiting) which simply
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> WHy not?
>
> >writes the privileges of the current process to PRIVS.TXT.
> >We first execute FILE.EXE from the shell to show that the user has the
> >default privileges.
> >FILE.EXE is then executed with higher privileges from the program that
> >we are exploiting (install, tcpip and telnet, but there are others as
> >well).
>
> >Oh, and you need the vmware codecs installed to watch the videos.
>
> Why not .MPG which doesn't require the download of some questionable
> software from some site on the internet?
an .avi file.
You can recode it yourself if you feel that it is a problem.
Unfortunately the codec for vmware vary in quality.
If you run the movie on a Linux box with vmware installed it should
display just fine.
dav...@alpha1.mdx.ac.uk
>Verified (finally got my VMS box up):
>
>$ show sys/noproc
>OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:20.73 Uptime 0
>23:14:17
>$ type .plan
>%n
>$ show sys/noproc
>OpenVMS V8.3 on node CHIMPY 15-AUG-2008 09:27:25.34 Uptime 0
>23:14:21
>$ finger sampsa
>Login name: SAMPSA In real life: SAMPSA LAINE
>Account: SAMPSA Directory: SYS$SYSDEVICE:
>[SAMPSA]
>Last login: Fri 15-AUG-2008 09:26:39
>No unread mail
>address=0000000000000000, PC=FFFFFFFF80BA3BA4, PS=0000001B
>
> Improperly handled condition, image exit forced.
> Signal arguments: Number = 0000000000000005
> Name = 000000000000000C
> 0000000000000004
> 0000000000000000
> FFFFFFFF80BA3BA4
> 000000000000001B
>
> Register dump:
> R0 = 0000000000000000 R1 = 0000000000000049 R2 =
>000000007BEEDCD0
>0000000000000000
> R6 = 000000007AE26928 R7 = FFFFFFFFFFFFFFFF R8 =
>000000007BF628E8
> R9 = 0000000000050011 R10 = 00000000000202D0 R11 =
>0000000000000000
> R12 = 0000000000116C88 R13 = 0000000000000000 R14 =
> R15 = 0000000000116BC8 R16 = 0000000000050011 R17 =
> R18 = 000000007AE26DB0 R19 = 000000007AE26930 R20 =
>0000000000000008
> R21 = 0000000000000000 R22 = 0000000000000000 R23 =
>0000000000000000
> R24 = 0000000000000000 R25 = FFFFFFFFFFFFEC96 R26 =
>0000000000000001
> R27 = FFFFFFFF80BA36D0 R28 = FFFFFFFF80BA3B30 R29 =
> SP = 000000007AE26880 PC = FFFFFFFF80BA3BA4 PS =
>000000000000001B
>
The same happens on Alpha VMS 7.3-1 with
Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
and it happens with %n in a .project file as well as a .plan file.
Whilst I was at it I thought I'd check what happened with % in front of other
characters.
so I set up a .plan file with
%a
%b
%c
%d
%e
%f
%g
%h
%i
%j
%k
%l
%m
%o
%p
%q
%r
%s
%t
%u
%w
%x
%y
%z
%0
%1
%2
%3
%4
%5
%6
%7
%8
%9
%
(note missing %n for obvious reasons)
The results were interesting
Alpha2:finger XXXXXX1
Username Program Login Term/Location
XXXXXX1 TCPIP$FINGER Fri 11:39 ALPHA2::YYYYYY
Login name: XXXXXX1 In real life:
Account: Directory: USERZ:[XXXXXX]
Last login: Fri 15-AUG-2008 11:39:56
Unread mail: 494
Plan:
a
b
0
-6.179570e+307
0.000000
0
65536
j
k
m
626550
106D0
q
r
.project
t
2080207092
v
w
20500
y
z
Alpha2:
I'm not really familiar with finger .project and .plan files but is
% supposed to do this sort of thing ? I thought the .plan and .project files
were just supposed to be a pure text file which was displayed.
bu...@signedness.org
> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
As we have mentioned earlier we have no output stream to write the
output of 'show proc/priv' to when executing the shellcode.
That is the reason for using the FILE.EXE program.
R.A.Omond
> [...snip...]
>
> The same happens on Alpha VMS 7.3-1 with
> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>
> and it happens with %n in a .project file as well as a .plan file.
>
> Whilst I was at it I thought I'd check what happened with % in front of other
> characters.
>
> so I set up a .plan file with
>
> %a
> [...snip...]
As far as I can see, this is probably very sloppy programming in
TCP/IP's Finger client. It looks like the "%<letter>" is being
interpreted by the C RTL, which is probably expecting some other
argument(s) to format according to the "%<letter>".
Looking at the PC from the access violation:
Wizard» anal/sys
OpenVMS system analyzer
SDA> map FFFFFFFF80BA3BA4
Image Resident Section Base End Image Offset
DECC$SHR_EV56 80A94000 80C909FF 0010FBA4
VAXman-
>should be more than enough to hit something you cant write to and
>crash the finger client (provided that HP has not patched it, we have
>not heard from them in weeks even though we asked for updates)
I don't run finger but I enabled it to see what you are on about.
I get nothing but a stream of %n%n%n%n%n%n back.
>System service numbers seems to move around between releases (like
>windows system calls), since all our payloads assumes 8.3 (alpha) and
>7.3 (vax) it would probably just mean that we get another bunch of
>replies saying "it only crashes the binary and won't get "SYSTEM"".
>Another thing is that at least the VAX shellcode was written purely
>for demo purposes and got my username hardcoded into it (uses a system
>service to enable all privs on my account)
>
>If anybody is in or around London I'd be happy to settle whether or
>not we are bullshitting with a live demo at a dc4420 meeting or
>similar event..
>
>The alpha exploits uses the sys$creprc system service to execute the
>file FILE.EXE that happens to show the privs of the process. The
>reason we took that route instead of spawning a new "shell" with
>higher privs is that it was easier to test/debug.
Why SYS$CREPRC to get privs? Why not SYS$GETJPI?
>btw for those of you who doubt us, check this out
>http://www.securityfocus.com/archive/1/495207 either we set a new
>trend making it fashionable to bullshit about OpenVMS bugs or maybe it
Multinet!
bu...@signedness.org
> >trend making it fashionable to bullshit about OpenVMS bugs or maybe it
>
> Multinet!
>
> --
> 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.
Why SYS$CREPRC to get privs? Why not SYS$GETJPI?
SYS$CREPRC is used in the shellcode to allow for arbitrary programs to
be
run with inherited privileges. SYS$GETJPI is used by the FILE.EXE
program to _get_
privileges and print them to a file.
That should be obvious to any OpenVMS user.
Simon Clubley
> dav...@alpha1.mdx.ac.uk wrote:
>
>> [...snip...]
>>
>> The same happens on Alpha VMS 7.3-1 with
>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2
>>
>> and it happens with %n in a .project file as well as a .plan file.
>>
>> Whilst I was at it I thought I'd check what happened with % in front of other
>> characters.
>>
>> so I set up a .plan file with
>>
>> %a
>> [...snip...]
>
> As far as I can see, this is probably very sloppy programming in
> TCP/IP's Finger client. It looks like the "%<letter>" is being
> interpreted by the C RTL, which is probably expecting some other
> argument(s) to format according to the "%<letter>".
>
I suspect that anyone who's written some C code knows what TCP/IP
Engineering have almost certainly done while writing the finger
client code.
I also suspect that, like me, many programmers here with C experience
also regard this as a first year undergraduate type programming mistake
and that code review procedures should have stopped this type of mistake
from _ever_ appearing within production code for a enterprise quality
operating system.
I wonder how many other mistakes like this are just waiting to be found
within the UCX code base ?
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
dav...@alpha1.mdx.ac.uk
code as the TCPIP stack for Tru64 I wondered whether that would have the same
problem.
A quick test on a Tru64 V5.1B box showed that it doesn't have this problem.
David Webb
Security team leader
CCSS
Middlesex University
VAXman-
>On Aug 15, 1:11 pm, VAXman- @SendSpamHere.ORG wrote:
>> In article <6e77d46c-8fd3-4b11-be3b-64f53ae45...@y38g2000hsy.googlegroups.com>, b...@signedness.org writes:>{...snip...}
>output of 'show proc/priv' to when executing the shellcode.
>That is the reason for using the FILE.EXE program.
OK. Perhaps I don't understand your "shell code" comment. You report
that you are executing DCL (shell) commands. I have no problem getting
output from SHOW PROCESS/PRIVILEGE from a DCL 'shell'.
VAXman-
{...snip...}
>SYS$CREPRC is used in the shellcode to allow for arbitrary programs to
>be
>run with inherited privileges. SYS$GETJPI is used by the FILE.EXE
>program to _get_
>privileges and print them to a file.
>That should be obvious to any OpenVMS user.
OK. I'm most confused. How do you invoke SYS$CREPRC from DCL?
Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
the SPAWN command. Are you spawning the FILE.EXE program? You've
been incessantly terse explaining this.
sam...@gmail.com
> OK. I'm most confused. How do you invoke SYS$CREPRC from DCL?
>
> Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
> the SPAWN command. Are you spawning the FILE.EXE program? You've
> been incessantly terse explaining this.
I think you might be confused (not saying you are) by the term
"shellcode".
It means the machine code payload of the exploit, typically used to
launch a shell,
not some kind of DCL script, therefore the SYS$CREPRC call is made
from
machine code, not DCL.
Sampsa
VAXman-
>On Aug 15, 2:10=A0pm, VAXman- @SendSpamHere.ORG wrote:
>> OK. =A0I'm most confused. =A0How do you invoke SYS$CREPRC from DCL? =A0
>>
>> Also, I just scanned all of DCL and the only SYS$CREPRC in it is in
>> been incessantly terse explaining this.
>
>"shellcode".
>
>It means the machine code payload of the exploit, typically used to
>launch a shell,
>not some kind of DCL script, therefore the SYS$CREPRC call is made
>from
>machine code, not DCL.
And where does this come into play in the 511 characters and 3 up arrows?
Richard B. Gilbert
ISTR that UCX 5.x was based on a port of the Unix/Ultrix TCP/IP. I also
seem to recall that 5.x was significantly better than UCX 3.x and 4.x.
Not perfect but a huge improvement. Did anyone but me EVER get a DNS
server running under UCX 3.3? (Hint, you were dead in the water until
ECO-13 came out!) The relationship between the documentation and what
the code actually did and/or expected from you was one of those
mysteries. . . . I needed, and got, a LOT of high powered technical
help. . . . Thank you Smiley Smith and Karol Zielonko.
Ten years ago, the code base was FULL of those little mistakes. DEC
could have saved a lot of money and pain by buying a WORKING TCP/IP
stack from TGV or Wollongong.
sam...@gmail.com
> In article <bd97f922-ae8b-44d1-929d-25948e061...@2g2000hsn.googlegroups.com>, samp...@gmail.com writes:
> >It means the machine code payload of the exploit, typically used to
> >launch a shell,
> >not some kind of DCL script, therefore the SYS$CREPRC call is made
> >from
> >machine code, not DCL.
>
> And where does this come into play in the 511 characters and 3 up arrows?
I think what they do (more or less) is to inject some shellcode into a
logical before running the exploit, then insert some other code after
the overflow that executes the code in the logical. Signedness guys
care to comment, I didn't see the demo, just have the notes second
hand?
Sampsa
sam...@gmail.com
wrote:
> Ten years ago, the code base was FULL of those little mistakes. DEC
> could have saved a lot of money and pain by buying a WORKING TCP/IP
> stack from TGV or Wollongong.
Interesting, especially considering they're still popping up (mind
you, in fairly obscure
tools such as the FINGER client). I wonder what the general state of
that codebase
is nowadays.
Sampsa
Richard B. Gilbert
If the Berkeley code ca. 1995 had it wrong, DEC just copied the bugs!
DEC was pretty much starting from zero. "A stern chase is a long
chase!" I think we've caught up with the rest of the world now but
there certainly werer some "interesting times" back then!
R.A.Omond
> [...snip...]
> I think what they do (more or less) is to inject some shellcode into a
> logical before running the exploit, then insert some other code after
> the overflow that executes the code in the logical. Signedness guys
> care to comment, I didn't see the demo, just have the notes second
> hand?
Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
but I actually didn't understand what that is meant to mean.
I'm a skeptic and proud of it, but I'm beginning to suspect that
this is all a hoax.
sam...@gmail.com
> samp...@gmail.com wrote:
> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...)
> but I actually didn't understand what that is meant to mean.
>
> I'm a skeptic and proud of it, but I'm beginning to suspect that
> this is all a hoax.
Ok, I'll have a go at making that more understandable:
1. The input (=shellcode) after the overflow will be executed by the
process with elevated privileges
2. There are quite a few input restrictions in what can be fed in
through the CLI, making any meaningful attack difficult through just
placing some shellcode after the overflow.
3. It is possible to execute shellcode stored in logicals, however.
4. Therefore the code injected after the overflow executes some other
code stored in a logical.
Sampsa
johnwa...@yahoo.co.uk
I've only been on VMS (and Unixes) since 1985 so I am not worthy, and
am risking teaching you how to suck eggs...
The general principle being referred to in the extract you quote is
that these exploits work by finding some OS-managed storage which is
writable by users and can potentially be executed later, preferably by
code with elevated privileges. So, for example, the name and/or
contents of a logical are in writable storage, and although that
storage isn't normally intended to hold code, if the memory management
subsystem doesn't prevent it being treated as code, then it can be
treated as code. So, you put some string of values in there somehow
that you want executed later, and all that's left to do is getting
control transferred to that code.
The classic mechanism for this unintended transfer of control is the
stack based buffer overflow scribbling over a return address. Here an
unchecked copy into a limited-size buffer is allowed to deposit more
data than the item can hold (which is why STR$this and DSC$that and
associated RTL routines are a NICE idea, one day maybe Billco and UNIX
will catch on to it). In the right circumstances, the excess data goes
far enough up(down?) the stack to overwrite the original return
address on the stack. Then all you have to do is work out how to get
the address of your "shell code" (?) written on to the stack in
exactly the right place to be interpreted as a return address when the
function in the picture returns to the caller (or in this case,
"returns" to the shell code).
If all this is done correctly you don't see an ACCVIO, you just end up
with unintended code being silently executed, potentially in the
context of an exploitable program. I haven't watched the videos but
the ACCVIOs here aren't what I'd expect to see as part of a successful
exploit; they are what I'd expect to see as the result of a bit of
traditional broken UNIX code with a traditional off-by-one or similar
schoolboy error (like the ones I still make :)). I'm entirely happy
that these things can be done in general, especially on commodity
OSes, and may even be possible on VMS, especially on apps with a UNIX
heritage which haven't been kept up to date.
I'm reserving judgement on whether I've seen proof.
Tom Linden
Previous post indicated multinet
http://www.securityfocus.com/archive/1/495207
--
PL/I for OpenVMS
www.kednos.com
sam...@gmail.com
> Previous post indicated multinethttp://www.securityfocus.com/archive/1/495207
>
> --
> PL/I for OpenVMSwww.kednos.com
That's a different flaw, I've verified the client bug on a stock
OpenVMS 8.3 install with TCPIP V5.6-9ECO2.
Sampsa
VAXman-
>> but I actually didn't understand what that is meant to mean.
>>
>> I'm a skeptic and proud of it, but I'm beginning to suspect that
>> this is all a hoax.
>
>
>process with elevated privileges
>2. There are quite a few input restrictions in what can be fed in
>through the CLI, making any meaningful attack difficult through just
>placing some shellcode after the overflow.
>3. It is possible to execute shellcode stored in logicals, however.
>4. Therefore the code injected after the overflow executes some other
>code stored in a logical.
I've mucked around quite a bit in DCL and I don't see how you get some
command or command procedure (shellcode) stored in a logical to be ex-
ecuted by DCL when you ACCVIO an image.
Graham Burley
>> And which finger (TCP/IP Services, Multinet, ...)
>>
>Previous post indicated multinet
>http://www.securityfocus.com/archive/1/495207
That finger bug's been fixed, Process released the FINGER-010_A052
patch for Multinet on 8th August. This appears to be something else.
Jan-Erik Söderholm
> If all this is done correctly you don't see an ACCVIO, you just end up
> with unintended code being silently executed, potentially in the
> context of an exploitable program. I haven't watched the videos but
> the ACCVIOs here aren't what I'd expect to see as part of a successful
> exploit;
IOW, isn't the ACCVIO a *proof* that the exploit was
*un*-successful ? They tried, but VMS "got them"...
Jan-Erik.
bu...@signedness.org
You really don't get it. At all.
It has nothing to do with running code in a logical when a program
_causes_ an access violation
since the exploit take advantage of an error to take control of the
execution flow.
Since the PC is controlled in the CLI bug we simply jump to the
address of a logical that contains the
shellcode that we want to run.
In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
shellcode to execute
the create process system service which in turn executes FILE.EXE.
However, we did not bother
to add a clean exit after the create process shellcode so the process
crashes when FILE.EXE
has been executed.
This is not a problem since FILE.EXE already have been executed with
the privileges of the target program inherited.
Please pick up some book on exploit development and think a little
before doing statements
about things that you obviously don't know anything about.
bu...@signedness.org
wrote:
Yeah right .... You should probably get a book about exploit
development as well.
Jan-Erik Söderholm
OK, The process ACCVIO's *after* your code has run.
If so, there might be a "problem"...
Simon Clubley
> On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote:
>>
>> I've mucked around quite a bit in DCL and I don't see how you get some
>> command or command procedure (shellcode) stored in a logical to be ex-
>> ecuted by DCL when you ACCVIO an image.
>>
>
I think that Brian may be thinking that shellcode is a series of DCL
commands instead of machine code. I think it's already been pointed
out on this thread already what the definition of shellcode is in the
context that you are using it, but Wikipedia has a writeup in case
Brian missed the earlier message:
http://en.wikipedia.org/wiki/Shellcode
VAXman-
>On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote:
No, as you really haven't explained it! At all.
>It has nothing to do with running code in a logical when a program
>_causes_ an access violation
>since the exploit take advantage of an error to take control of the
>execution flow.
>Since the PC is controlled in the CLI bug we simply jump to the
>address of a logical that contains the
>shellcode that we want to run.
You keep talking about shellcode. That's scripting in unix... what the
fuck ARE you talking about?
>In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
>shellcode to execute
>the create process system service which in turn executes FILE.EXE.
>However, we did not bother
>to add a clean exit after the create process shellcode so the process
>crashes when FILE.EXE
>has been executed.
>This is not a problem since FILE.EXE already have been executed with
>the privileges of the target program inherited.
Send me your so called "shellcode" and FILE.EXE then along with some
instuctions other than typing 511 characters and 3 up-arrows.
>Please pick up some book on exploit development and think a little
>before doing statements
>about things that you obviously don't know anything about.
Yeah, I know nothing about VMS. Please, oh great one, teach me your
weirding way.
Fuck off! You come here claiming to have found some great exploit but
you won't clearly explain yourself. Then, when you're questioned about
it, you cleverly -- as cleverly as you've explained yourself -- resort
to insult.
JF Mezei
> That is the reason for using the FILE.EXE program.
Does FILE.EXE need to be installed with privileges and/or executed from
an account with elevated privileges ?
Wilm Boerhout
[snip]
>> In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a
>> shellcode to execute
>> the create process system service which in turn executes FILE.EXE.
>> However, we did not bother
>> to add a clean exit after the create process shellcode so the process
>> crashes when FILE.EXE
>> has been executed.
>> This is not a problem since FILE.EXE already have been executed with
>> the privileges of the target program inherited.
>
> Send me your so called "shellcode" and FILE.EXE then along with some
> instuctions other than typing 511 characters and 3 up-arrows.
Exactly! The scientific method requires that "bugs" publish a
reproducer, with instructions clear enough for all of us. It would also
help if he provided a translation table to convert his arcane
incantations to our own.
So far, from the discussion, I'm convinced bugs wouldn't recognize a VMS
security flaw if it danced naked on his head and sang "Happy Days Are
Here Again". (Oh, Blackadder, where hast thou gone?)
--
Wilm Boerhout Zwolle, NL
remove OLD PAINT from return address to reply
JF Mezei
> OK. I'm most confused. How do you invoke SYS$CREPRC from DCL?
$HELP SPAWN
$HELP RUN process
and to the original poster:
$HELP SHOW PROCESS /OUTPUT
JF Mezei
> 3. It is possible to execute shellcode stored in logicals, however.
> 4. Therefore the code injected after the overflow executes some other
> code stored in a logical.
Since there is no such thing as "shellcode" in VMS, it would greatly
help if you use terminology native to VMS so we could understand it.
For an application to execute the content of a logical name, it would
need to first extract those contents into memory, and then declare that
area of memory to be executable and then branch to it. This doesn't
happen by mistake/luck.