INFO-VAX Mon, 18 Aug 2008 Volume 2008 : Issue 451 Contents: Re: CD written on Alpha won't mount on Integrity DVD ROM Re: DEFCON 16 and Hacking OpenVMS RE: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS RE: DEFCON 16 and Hacking OpenVMS RE: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: invalidating I-cache on I-tanium Re: invalidating I-cache on I-tanium Re: invalidating I-cache on I-tanium Little question about audit (and alarm) ACEs Old DECservers, DEChubs etc. available to a good home. ---------------------------------------------------------------------- Date: Mon, 18 Aug 2008 12:50:20 -0500 From: Bob Blunt Subject: Re: CD written on Alpha won't mount on Integrity DVD ROM Message-ID: baldrick wrote: > Evidently I think I've done something wrong here so here's the short > version of the conditions and symptoms, plus a little background. > > We're migrating data from a VAX to a recently installed Integrity Blade. > > I'd like to leave the theological arguments out of this, but I thought > it would be nice to have the VAX data on a CD so we retain it as an > archived starting point, and allows us to copy the data from the CD onto > the new server. > > Objective: Alpha data on newly burned CDR, mounted on Blade and copied. > Problem: Cannot mount CDR on Blade! (VAX and Alpha's no problem). > > Blades are new territory, and using HP SIM (even installing it), using > it, installing VMS is an entertainment in itself. This will be subject > of a VMS podcast before too long. However overall I'm impressed and if > this is the future, bring it on! But I'm straying from the point... > > After connecting the DVD ROM, getting VMS installed, and logging in, I > put my CD into the DVD ROM and tried to mount... > > $ mount/over=id dna0: > %MOUNT-W-IDXHDRBAD, index file header is bad; backup used > %MOUNT-F-MAPHDRBAD, storage map header is bad; volume locked > > And the CD is not mounted. > > $ mount/fore dna0: > %MOUNT-I-MOUNTED, CHANGED mounted on _IIIIII$DNA0: > > However a foreign mount is not much use to me. > > [Note: I have NOT tried the virtual connect of the ISO using SIM] > > $ sh dev d/full > > Disk DNA0:, device type HP......Virtual CD-ROM.., is online, mounted, > software > write-locked, file-oriented device, shareable, available to cluster, > error > logging is enabled. > > But note on the Blade system is shows as a virtual connected device. It > is a HP BLc3000 DVD Drive ($ sh dev d/full > > Disk DNA0:, device type HP......Virtual CD-ROM.., is online, mounted, > software > write-locked, file-oriented device, shareable, available to cluster, > error > logging is enabled. > > This is showing as a virtual connected drive, but is a HP BLc3000 DVD > Drive (DVD/CDRW) mounted in the blade chassis. > > The process used was to make a disk to disk saveset backup of the data, > copy to Alpha, use LDRIVER and CDRECORD to make a CD, and I even > performed (as routine) an ANAL/DISK/READ which passed, apart from > > $ anal/disk dka400: > Analyze/Disk_Structure for _$5$DKA400: started on 5-AUG-2008 11:44:27.59 > > %ANALDISK-I-SHORTBITMAP, storage bitmap on RVN 1 does not cover the > entire device > %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS > -SYSTEM-W-NOSUCHFILE, no such file > > This is on a (Toshiba) RRD46 type device. When performing the same > command on the YAMAHA CRW2100S (writer) it completes with no > SHORTBITMAP error. I use RITEK media. > > Here is the summary of what I'm doing to create the CD, its a process i > have not changed for some while. I am using Alpha 8.3 with current patches. > > cdrecord -version > Cdrecord 1.10 (Alpha/VAX-CPQ-VMS/OpenVMS) Copyright (C) 1995-2001 Jörg > Schilling > > ld version > %LD-I-VERSION, LD version V8.2, module X-8 built on Jun 29 2006 17:51:35 > -LD-I-DRIVERVERSION, Driver version: 29-JUN-2006 18:18:50.92 > -LD-I-SYSINFO, Node: ZZZZZZ::, Hardware: AlphaServer 800 5/500, VMS > version: V8.3 > > This is the container create command: > > ld create /siz='filsiz' disk$d0:[000000]staging.dsk > > where filsiz is 1437408 I believe this to be the closest safest maximum > addressable data area on a standard "700 MB" cdr. I arrived at this > after some experimentation. > > My INIT command for the container file is: > > init lda1:/index=end/nohigh/system/cluster=4/erase/max='maxfil' 'label' > > and my CDRECORD command is > > cdrecord -v -speed=8 -dev=0,6,0 -driveropts=burnproof -data > disk$d0:[000000]staging.dsk > > [Notes: burnproof doesn't actually work, and I'm using a copy I built > not the standard VMS supplied COPY/RECORDABLE] > > I believe the process I am using SHOULD work, indeed for Alpha and VAX I > have no problems with CDs made this way, but I want to understand what's > going wrong here. Is my INIT command for the volume at fault? Is the > writer not creating a fully compatible disc? Will using COPY/RECORDABLE > make a better copy? If you think the answer will make for a good copy > and not a coaster then i am all ears. > > Nic. > > PS. If anyone suggests "why don't I copy this over the network", they'll > find themselves on the receiving end of the fish slapping dance from > Monty Python. The number of different formats and "sizes" available in the "real world" for CD and DVD is amazing. I've gotten two units working in my lab, one Philips CDD-521 attached to my Infoserver and a "stab-in-the-dark, sometimes you just gotta say WTF and try it" HP writable SCSI CD drive on one of my Alphas. I think the latter is a 6620 or something. It works with CDRECORD pretty well. The key to getting both drives working was the blank media. NEITHER one worked with anything but the old 650mb blanks. To quote one of my coworkers, I was making nothing but "coasters" with the 700mb CD blanks that are much, much more common today. So unless you're using CD or DVD drives with the exact same features and compatibilities on all the systems, it feels to me like you've got mismatched formats and the more modern drive can't read the older drive's output. The Infoserver won't allow "just any drive" because it looks for specific models (finding a working Philips was a miracle) so you can't just put a newer writable SCSI DVD unit in place. CDRECORD should be more flexible but may still leave you with a mismatch if your writer isn't writing what your reader can read. At least on Alpha with CDRECORD (or native tools) you've got more options. Unless, of course, you can move the drive that wrote the CD to the Itanium and get it working there. You might also try using a current OpenVMS release on Alpha, turning on the Infoserver bits and serving the written CD to your Itanium... bob ------------------------------ Date: Mon, 18 Aug 2008 01:10:47 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <586bd370-11a1-49bd-aba4-b8ef2f4f7897@m44g2000hsc.googlegroups.com> On Aug 18, 4:19=A0am, JF Mezei wrote: > b...@signedness.org wrote: > > played around with DCL commands and asked about FILE.EXE in the first > > place. > > While battling headwids today on my bike, I was thinking about this. > > You had machine code being executed as part of a utility like INSTALL. > This would be running inside that process and inherit all of the > process' profile. You mentioned that this machine code created a > subprocess with SYS$CREPRC, and that subprocess ran that FILE.EXE, correc= t ? > Correct. > Now, if that subprocess was created to run FILE.EXE, it means that it > would not have a DCL environment below it, and not have access to many > functions. > > What you could have done is create a subprocess that runs > SYS$SYSTEM:LOGINOUT.EXE with input being the current terminal device, > and output being the currnet terminal device (you would have then had > access to the $ sign and any DCL commands). > > Alternatively, you could have had the input set to a file containing DCL > command (a command procedure (aka: unix shell script) and that command > procedure would have had full access to SHOW PROCESS/OUTPUT=3Dxxx or RUN > FILE.EXE. > Yes.. we were a bit lazy but the shellcode is easy to modify for remote exploitation (just replace file.exe with suitable command to run) without having to worry about input/output streams. For local exploitation I suppose a new instance of DCL with privs would be cleaner. > Finally, the machine code stub that you had "embedded" into the utility > in the mother process (via a logical name) would need to know a bit more > about how it is being called. > > If the utility simply branches to your code, then your code would have > no way of knowing where to branch back once it has completed its work. > If the utility calls your code as a subroutine, then you could do all > you want inside your subroutine and return to the caller cleanly and let > the utility continue it merry way. > > However, the utility might expect some results from that subroutine and > if your covert code-in-a-logical doesn't provide those results, the > mainline code from the utility might barf with some invalid data. > > AKA: it would be pretty hard to make it appear totally transparent so > that the user would have no knowledge that something untowards was done > behind the scenes. Things are done "in reverse" here, we are not calling our code we are "returning to it". So we don't really have the option to choose how it is going to be called. As you point out we also overwritten the original return address for the function.. There may be enough information intact to intelligently recalculate the return address and return (not had my morning coffee yet and alpha isn't exactly my favorite platform so don't hold me to it), or at the very least scan memory for the right address to return to. We used these techniques in the past in kernel exploits where it really is game over for you if you don't clean your own mess up. Here it isn't really a problem. You are not relying on another user to execute the code for you so you don't really have to hide it. I suppose someone could log the access violation and that it could give you away, but then would be easier to terminate the process cleanly from the shellcode rather than repairing the stack. ------------------------------ Date: 18 Aug 2008 06:28:47 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: RE: DEFCON 16 and Hacking OpenVMS Message-ID: In article , "Main, Kerry" writes: > > I am not trying to pass judgement one way or another. And most in this > newsgroup would never state that OpenVMS is technically unhackable > and/or not susceptible to security issues. > > Simply that it is much more difficult than most of the other OS's. > On what basis do you make that statement as general as that ? For example, RedHat Linux now has SELinux built in, so that even if a service gets compromised, there's the possibility that the attacker will be constrained (at least at operating system level as opposed to application level). The SMG exploit discussed here uses the same attack mechanism (buffer overflow/stack trashing) as on other operating systems and once the vulnerability was discovered, VMS security didn't make a difference to been able to exploit a privileged program. I have three related questions for you: 1) The %n UCX finger client issue appears to be a case of the programmer writing something like printf(untrusted_text); instead of the safer printf("%s", untrusted_text); If that's confirmed, then that's a student level programming mistake that should never have been made in the first place, and if it was, then it should have been caught by normal code review processes. If that's confirmed as the cause what do you think about having very poor quality code like that within the UCX code base ? What do you think about the fact that it was missed during code review ? As for me, I'm worried about what the programmer who wrote that may have done in the rest of the UCX code base. 2) The DNS issues still haven't had a formal patch released. Although you can go and ask for the patches if you know they exist, they still have not been announced as a formal patch. As you remind us at every opportunity, other vendors announce security patches to their customers. What do you think about UCX engineering not issuing a formal announcement of a security issue ? 3) The DNS issue was a high profile event. How many other security issues have been discovered within UCX and for which there are patches available, but we don't actually know about because UCX engineering have not bothered to announce the patch ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: 18 Aug 2008 06:32:29 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , bugs@signedness.org writes: > On Aug 18, 5:36 am, "Ken Robinson" wrote: >> This has been a very interesting and informative (for the most part) >> thread. I believe that "bugs" has performed a very good service for >> VMS and should be thanked, not shouted down. I also think that he (and >> his organization) should be invited to the next OpenVMS Technical Boot >> Camp (assuming there is one) next May so he can talk directly to the >> VMS Engineers and Product managers. He should also be allowed to give >> a presentation on how to find these vulnerabilities. I would certainly >> go to a sessions like that. > > Thanks a lot for your support! > We will be more than happy to help out in any way that we can. > Likewise, I would like to say thanks for following standard industry procedures and dealing with this in a responsible manner. >> BTW, I couldn't see the videos even on a VMware server running CentOS >> 5.1. Also, downloading the necessary codec to my Windows XP laptop >> didn't help. > > Hmmz, we should probably look into converting these videos to a more > portable format. > I can not understand why VMWare uses some private codec. > The videos don't play under Xine for me, but they do play with a version of MPlayer built with the full MPlayer extended codec pack compiled in. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Mon, 18 Aug 2008 12:26:00 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E494.8264364F@SendSpamHere.ORG> In article , JONESD@ecr6.ohio-state.edu (David Jones) writes: >In message , > bugs@signedness.org writes: >>Btw, any suggestions on how to trigger this automatically without >>using a custom telnet/ssh client? > >So your goal is to create a trojan horse program that secretly breaks in >when a non-privileged user runs it? > >>Using popen() or an input file with lib$spawn does not work (popen() >>is probably implemented using lib$spawn), because the input is not a >>terminal why the vulnerable code is not used. > >If SMG doesn't think input is from an interactive terminal, there is no >editting so there is no need to try to interpret escape characters. > >You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED >process to it. The parent process controlling the terminal doesn't need to >supply a password and none of the dialog needs to be displayed. Use the >exploit to grant that spawned process privileges and then just use that session >to do other things with the empowered process. I don't believe that discussing how to "weaponize" this exploit is a good idea for public discussion here in c.o.v. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Mon, 18 Aug 2008 06:56:25 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 18, 2:26 pm, VAXman- @SendSpamHere.ORG wrote: > In article , JON...@ecr6.ohio-state.edu (David Jones) writes: > > > > >In message , > > b...@signedness.org writes: > >>Btw, any suggestions on how to trigger this automatically without > >>using a custom telnet/ssh client? > > >So your goal is to create a trojan horse program that secretly breaks in > >when a non-privileged user runs it? > > >>Using popen() or an input file with lib$spawn does not work (popen() > >>is probably implemented using lib$spawn), because the input is not a > >>terminal why the vulnerable code is not used. > > >If SMG doesn't think input is from an interactive terminal, there is no > >editting so there is no need to try to interpret escape characters. > > >You can create a psuedo-terminal and direct the input/output of a LIB$SPAWNED > >process to it. The parent process controlling the terminal doesn't need to > >supply a password and none of the dialog needs to be displayed. Use the > >exploit to grant that spawned process privileges and then just use that session > >to do other things with the empowered process. > > I don't believe that discussing how to "weaponize" this exploit is a good > idea for public discussion here in c.o.v. If it was up to you to decide what should be in this group it would only be a maximum of two posts in every thread, the first post with a question and a second post with a correct answer from you. > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM > > ... pejorative statements of opinion are entitled to constitutional protection > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) > > Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside > of usenet _must_ include its contents in its entirety including this copyright > notice, disclaimer and quotations. ------------------------------ Date: Mon, 18 Aug 2008 14:04:07 +0000 From: "Main, Kerry" Subject: RE: DEFCON 16 and Hacking OpenVMS Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED5D1F0F0@GVW1158EXB.americas.hpqcorp.net> > -----Original Message----- > From: Simon Clubley [mailto:clubley@remove_me.eisner.decus.org- > Earth.UFP] > Sent: August 18, 2008 7:29 AM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: DEFCON 16 and Hacking OpenVMS > > In article > t>, "Main, Kerry" writes: > > > > I am not trying to pass judgement one way or another. And most in > this > > newsgroup would never state that OpenVMS is technically unhackable > > and/or not susceptible to security issues. > > > > Simply that it is much more difficult than most of the other OS's. > > > > On what basis do you make that statement as general as that ? > No OS is 100% secure. No one here should ever state that. OpenVMS will occasionally have security issues identified. It has been discussed here many times before, but security arch requires it to be designed as part of the base OS - not added on later. Overview: http://h71028.www7.hp.com/ERC/downloads/4AA0-2896ENW.pdf It's also a question of the volume of security patches. Each platform can b= e made relatively secure with hand tuning and applying patches etc. However, with 5-20 new security patches being released every month, how do you ensure your platform continues to be secure when you have the challenges of having to re-test applications and platforms before new patches are rolled out? Again, no OS is 100% secure and other issues will potentially be found with OpenVMS in the future. That does not mean OpenVMS is not a very secure OS. Its history speaks for itself. There has been exploits, but very few. > For example, RedHat Linux now has SELinux built in, so that even if a > service gets compromised, there's the possibility that the attacker > will > be constrained (at least at operating system level as opposed to > application level). > Red Hat *monthly* security (not maint) issues can be found at: https://www.redhat.com/archives/enterprise-watch-list/ (click on thread for each month and add them up yourself) > The SMG exploit discussed here uses the same attack mechanism (buffer > overflow/stack trashing) as on other operating systems and once the > vulnerability was discovered, VMS security didn't make a difference > to been able to exploit a privileged program. > > I have three related questions for you: > > 1) The %n UCX finger client issue appears to be a case of the > programmer > writing something like > > printf(untrusted_text); > > instead of the safer > > printf("%s", untrusted_text); > > If that's confirmed, then that's a student level programming mistake > that > should never have been made in the first place, and if it was, then it > should have been caught by normal code review processes. > > If that's confirmed as the cause what do you think about having very > poor > quality code like that within the UCX code base ? What do you think > about > the fact that it was missed during code review ? > It has not been confirmed so why speculate until it has? Btw, not to say this is not a potential issue, but as you know, not every Cust uses TCPIP Services (Multinet, TCPware etc) > As for me, I'm worried about what the programmer who wrote that may > have > done in the rest of the UCX code base. > > 2) The DNS issues still haven't had a formal patch released. Although > you can go and ask for the patches if you know they exist, they still > have not been announced as a formal patch. As you remind us at every > opportunity, other vendors announce security patches to their > customers. > Did you not see the announcement at? http://h71000.www7.hp.com/network/new.html > What do you think about UCX engineering not issuing a formal > announcement > of a security issue ? > > 3) The DNS issue was a high profile event. How many other security > issues > have been discovered within UCX and for which there are patches > available, > but we don't actually know about because UCX engineering have not > bothered > to announce the patch ? > http://h71000.www7.hp.com/network/new.html > Simon. > > -- > Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP > Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: 18 Aug 2008 09:29:24 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: RE: DEFCON 16 and Hacking OpenVMS Message-ID: In article <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED5D1F0F0@GVW1158EXB.americas.hpqcorp.net>, "Main, Kerry" writes: > > Did you not see the announcement at? > http://h71000.www7.hp.com/network/new.html > Well, that is just great. :-( There's a standard place within HP for posting patches: ftp://ftp.itrc.hp.com/openvms_patches but instead, the UCX team have decided to go and place their patches at a non-standard location that we are not going to find unless we are told about it, in the way that you have just told us. The ITRC location is the place to go for patches, and there are automated tools that scan this location and notify the system manager of any new patches. Are there any other private locations within the VMS world for patches that various teams have setup that we should be aware of ? :-( I also note that the UCX team didn't provide a .TXT file detailing the contents of the patch. A .TXT file is also standard VMS patch procedure. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Mon, 18 Aug 2008 15:49:28 +0100 From: "Richard Brodie" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: "Simon Clubley" wrote in message news:U8rSo55epjHX@eisner.encompasserve.org... > The ITRC location is the place to go for patches, and there are automated > tools that scan this location and notify the system manager of any new > patches. When they have a proper patch, they will put it there - at the moment it's just a replacement image. I don't think there is much sense in complaining about the existance of a hotfix; it's not as if anyone will learn anything new by reverse engineering it. Feel free to complain about the timeliness of a formal patch though :) ------------------------------ Date: 18 Aug 2008 10:09:06 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , "Richard Brodie" writes: > > "Simon Clubley" wrote in message > news:U8rSo55epjHX@eisner.encompasserve.org... > >> The ITRC location is the place to go for patches, and there are automated >> tools that scan this location and notify the system manager of any new >> patches. > > When they have a proper patch, they will put it there - at the moment it's > just a replacement image. I don't think there is much sense in complaining > about the existance of a hotfix; it's not as if anyone will learn anything new > by reverse engineering it. Feel free to complain about the timeliness of > a formal patch though :) > It's not the existance of the hotfix that I am complaining about, but the lack of a formal announcement in the proper location, so that those of us who look in the proper place for patches or use scanning tools will find it. If the file is not a formal patch, which I thought it was based on Kerry's response, then my original comment stands. Kerry, where's the formal patch and the formal announcement ? It's unacceptable that there hasn't been a formal patch by now. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Mon, 18 Aug 2008 09:05:19 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <04770cca-13df-4103-9fc5-7f5b728f62e7@34g2000hsh.googlegroups.com> On Aug 18, 1:21=A0pm, VAXman- @SendSpamHere.ORG wrote: > In article , b...@signedness.org writes: > > > > >On Aug 17, 10:09 pm, VAXman- =A0@SendSpamHere.ORG wrote: > > >> >It was pointed to you that the codecs used in the videos are > >> >non-standard and cannot be watched by everyone. I also didn't even > >> >bother to download them. > >It is a VMWare recording for heavens sake (http://www.vmware.com)! > >If you have bothered to download the videos you would probably not > >have > >played around with DCL commands and asked about FILE.EXE in the first > >place. > > >> A cohesive explaination of reproducing the stack dump would have been > >> better than some video of a terminal session. =A0There was also a repo= rt > >> of no audio explaining what was happening in the video. > >It is a VMWare recording (http://www.vmware.com/), it has no sound. > >We used the videos in our presentation (and yes, we did actually > >talk while playing them). > > >> >Your introduction of FILE.EXE was absolutely confusing. This was not > >> >necessary. And reduced your credibility because it put the focus on t= he > >> >"file.exe" instead of on the actual vulnerability. > > >> Another valid point. > >Again, you did not watch the videos, i.e. you did not input all data > >before computing. > > >You continue to claim that we have done things wrong when trying to > >explain the vulnerability that you tried to wave away as a hoax. Your > >attitude strongly imply that this has nothing to do with terminology > >and codecs, but that your ego got bumped really hard, and you can not > >handle it. > > There's no need for you to be so condescending. > > It's not about ego. =A0I, and others here, were trying to determine if > this truly was a vulnerability. =A0The first reports were that this was > a vulnerability in the DCL CLI easily exploited with a buffer over- > flow. =A0The published instructions to cause the overflow did NOT pro- > duce the results reported. =A0_Your_ terminology was misleading -- not > the 'shellcode' thing either! > > As for your VIDEO... =A0I did, this past weekend, view the one called: > openvms_local_install_exploit.avi. =A0 > > 1. You telnet into a VMS system. > =A0 =A0(this command sting alone is confusing) > 2. delete PRIVS.TXT > 3. run FILE.EXE > 4. type PRIVS.TXT > =A0 =A0(privs output) > 5. delete PRIVS.TXT > 6. then you run LOADCODE leaving a prompt SHELLCODE>> > 7. from this point you execute INSTALL... etc., etc., etc. > > To me, it looks like you wrote your own CLI which is being used in > the spawned subprocess. =A0Again, this obfuscates the reality. > > >There is a bug for you to analyze. > > One the missing bits were properly explained, I was able to produce the > stack dump. > > I've written my OWN 'shellcode' now. =A0I load about 150 bytes of code to > P1 via a supported and documented user invokable mechanism! =A0This code > sets the AUTHPRIVs in the PHD and it returns cleanly via a SYS$EXIT with > SS$_NORMAL. =A0All of this executed in a normal DECwindows terminal. > > NOW, had you, perhaps: > > 1. not changed your prompt > 2. executed INSTALL from DCL > 3. not returned the BADPARAM stack > 4. explained, after the long string of AAAs, about the unseen I/O > > there would have been more and immediate credence placed in your claim. > > My question still is *WHY* FILE.EXE when SHOW PROCESS/PRIVILEGES would > have sufficed??? =A0Your claim was something about output capturing. =A0I > fail to see why you can capture normal terminal I/O from a TYPE command > but not from SHOW PROCESS/PRIVILEGES. =A0This is the type of thing that's > caused much of the confusion, doubt and distrust here. =A0I have no issue > invoking my SHOW PROCESS/PRIVILEGES before and after loading my code to > P1. =A0I don't need to SPAWN a sub-process; albeit, for testing, I did to > allow quick cleanup of P1 space with a logout. > > And, for the record, I did not proclaim this to be a hoax. =A0However, in > light of your, and others, instuctions which were muddled, incomplete, > and riddled with misleading jargon, I would expect that the good folks > of comp.os.vms would be dubious. > > FWIW, I have been in contact with a number of people working independ- > ently on patches to thwart this attack. =A0Interim fixes until a patch or > fix is released by HP. > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME= SIS(dot)COM > > ... pejorative statements of opinion are entitled to constitutional prote= ction > no matter how extreme, vituperous, or vigorously expressed they may be. (= NJSC) > > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article = outside > of usenet _must_ include its contents in its entirety including this copy= right > notice, disclaimer and quotations. Well congratulations, now you pissed me off too and not just cmn.. WE said nothing about DCL.. Our terminology misleading? Funny.. because it is a security issue, it was presented at a security conference, everyone there seemed to get it, and other people in this group got it too... If you don't understand what shellcode means, don't google it, or ask and then make the wrong assumptions that is hardly our fucking fault now is it? OH AND CONDESCENDING????? GIVE ME A FUCKING BREAK! Remember the "1337 haxOrz" Comment? What do you call that? Yeah we may not be old enough to remember the dinosaurs or having written code on punch cards... Well guess what, we still found and exploited multiple vulnerabilities in VMS.. even if we are not in the right little click of superior beings such as yourself.. Then you say discussing how to "weaponize" this exploit is not a good idea for public discussion.... We seem to recall demands that we release our exploit.... Double standards??? Oh and talking about your shellcode is ok? oh wait... it can't be that you still are trying to prove that you are superior to us for using a different method, can it? Or as another poster so elegantly put it:- "It's amazing how many people can *now* get the egg to stand on its end once they've been shown how :-( Oh, but your egg stands so much prouder." ------------------------------ Date: Mon, 18 Aug 2008 10:55:05 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: invalidating I-cache on I-tanium Message-ID: <48a938df$0$185$e4fe514c@news.xs4all.nl> diy code: .entry start,0 pushl #codelen pushal addr calls #2,g^sys$pal_imb ret codestart=. addr: .jsb_entry rsb codelen=.-codestart .end start Jur. VAXman- @SendSpamHere.ORG wrote, On 13-8-2008 16:59: > I've been writing some self-modifying Itanium assembly. Fun stuff if > you'd like to develope a deep routed psychosis. :) > > Anyway, while my code does work, it should, to be proper, invalidate > the I-cache. I looked at the macro INSTRUCTION_MB and it contains: > > .MACRO INSTRUCTION_MB address,length,?L1 > > .if ndf ALPHA > .if ndf IA64 > .ERROR 0 ; No architecture defined > .endc > .endc > > ===> .if df ia64 > ===> .warn ; Not yet flushing the Icache > ===> .endc > > .IF NDF SMP$V_ENABLED > $SPLCODDEF > .ENDC > .WEAK SMP$GL_FLAGS > .WEAK SMP$INTALL_ACQ > .WEAK SMP$INTALL_BIT_ACQ > MOVAB SMP$GL_FLAGS,R0 > BEQL L1 > BBC #SMP$V_START_CPU, - > G^SMP$GL_FLAGS,L1 > ASSUME SMP$V_ENABLED EQ 0 > BLBC G^SMP$GL_FLAGS,L1 > IPINT_ALL INV_ISTREAM > L1: > .if df alpha > EVAX_IMB > .endc > > > The .warn directive has me concerned. If "Not yet flushing the Icache", > why does the macro do an interprocessor interrupt? I'm hoping somebody > in VMS engineering is readign this and would answer. > ------------------------------ Date: Mon, 18 Aug 2008 12:39:57 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: invalidating I-cache on I-tanium Message-ID: <00A7E496.7532D338@SendSpamHere.ORG> In article <48a938df$0$185$e4fe514c@news.xs4all.nl>, Jur van der Burg <"lddriver at digiater dot nl"> writes: >diy code: > > .entry start,0 > > pushl #codelen > pushal addr > calls #2,g^sys$pal_imb > ret > >codestart=. > >addr: .jsb_entry > rsb > >codelen=.-codestart > > .end start > >Jur. Thanks Jur. This I know. My question was ABOUT the comment in the INSTRUCTION_MB macro. Also, for what I'm doing (modifying executive code) the I-cache should be invalidated on all participating CPUs; thus, implying, the interprocessor interrupt. ;) Strangely, there are defs in BLISS and C libraries but not in Macro. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Mon, 18 Aug 2008 16:11:02 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: invalidating I-cache on I-tanium Message-ID: <48a982ed$0$197$e4fe514c@news.xs4all.nl> Fwiw, sys$pal_imb does this for all cpu's. The lack of support in macro is probably an oversight. Jur. VAXman- @SendSpamHere.ORG wrote, On 18-8-2008 14:39: > In article <48a938df$0$185$e4fe514c@news.xs4all.nl>, Jur van der Burg <"lddriver at digiater dot nl"> writes: >> diy code: >> >> .entry start,0 >> >> pushl #codelen >> pushal addr >> calls #2,g^sys$pal_imb >> ret >> >> codestart=. >> >> addr: .jsb_entry >> rsb >> >> codelen=.-codestart >> >> .end start >> >> Jur. > > Thanks Jur. This I know. My question was ABOUT the comment in the > INSTRUCTION_MB macro. Also, for what I'm doing (modifying executive > code) the I-cache should be invalidated on all participating CPUs; > thus, implying, the interprocessor interrupt. ;) > > Strangely, there are defs in BLISS and C libraries but not in Macro. > ------------------------------ Date: Mon, 18 Aug 2008 15:37:20 GMT From: gerry77@no.spam.mail.com Subject: Little question about audit (and alarm) ACEs Message-ID: <4t4ja4l042aofjaua4dc5rjvfi12hogsb2@4ax.com> Hello everyone, I gave a quick look at the relevant manuals but did not find a definitive answer, so here is the question: what about something like the following? $ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=FAILURE) MYFILE.EXT I knew that in the ACCESS= portion of this type of ACE I had to specify something like READ+WRITE followed by +FAILURE or +SUCCESS in order to have a correct and working ACL, but I've just discovered that the above mentioned syntax is quietly accepted. Am I missing something? Thank you, G. ------------------------------ Date: Sun, 17 Aug 2008 23:14:42 -0700 (PDT) From: David B Sneddon Subject: Old DECservers, DEChubs etc. available to a good home. Message-ID: <9fa43783-a131-448a-9c8b-7856600aabe3@z11g2000prl.googlegroups.com> I am having an early springclean and have a lot of old DEChub90, DECserver90, DECbrouter90, DECrepeater90 (some fibre) and some DEChub900, DECswitch900s also 2 HSZ50s that are taking up a lot of room. I don't have an full inventory at the moment, but if anyone is interested in any of this stuff (*you pay the shipping*) let me know. All this stuff was working when it was decommissioned. I am located in Perth, Western Australia. If no-one wants it, it is being dumped. Dave ------------------------------ End of INFO-VAX 2008.451 ************************