INFO-VAX Wed, 20 Aug 2008 Volume 2008 : Issue 454 Contents: Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: Disk remains in HostUnavailable for a very long time Re: DS10L power supply mystery Re: DS10L power supply mystery Re: DS10L power supply mystery Re: DS10L power supply mystery Re: Storage Shelves for FREE Re: Storage Shelves for FREE Re: What to do now with a DEC Server 3000? Re: What to do now with a DEC Server 3000? ---------------------------------------------------------------------- Date: Tue, 19 Aug 2008 14:54:45 -0400 From: JF Mezei Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <48ab17ec$0$1817$c3e8da3@news.astraweb.com> Bob Koehler wrote: >> "Anybody who says his system is bulletproof is either a liar or stupid." >> >> Winn Schwartau > > Oh, come on. I have one of those. It's siting in the basement, > turned off and unplugged. I think that the all mighty Microvax II was probably litterally bullet proof when you consider the thick steel used to make the casing. :-) ------------------------------ Date: Tue, 19 Aug 2008 15:33:49 -0400 From: "Richard B. Gilbert" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: JF Mezei wrote: > Bob Koehler wrote: > >>> "Anybody who says his system is bulletproof is either a liar or stupid." >>> >>> Winn Schwartau >> Oh, come on. I have one of those. It's siting in the basement, >> turned off and unplugged. > > I think that the all mighty Microvax II was probably literally bullet > proof when you consider the thick steel used to make the casing. :-) I suspect that a 30-06 round, not even armor piercing, would probably go in one side and out the other. Are you allowed to own/use guns? ------------------------------ Date: Tue, 19 Aug 2008 20:43:14 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E5A3.230B9738@SendSpamHere.ORG> Hein's patch for this vulnerability is making its rounds and reports are that HP has one to be made available for public consumption shortly, I'd just like to offer this: Username: NOPRIV_USER Password: Welcome to the OpenVMS AXP Operating System, version V8.3 Last interactive login on Tuesday, 19-AUG-2008 16:11:08.58 $ SET TERMINAL/UNKNOWN $ SHOW PROCESS/PRIVILEGES 19-AUG-2008 16:20:58.13 User: NOPRIV_USER Process ID: 00000245 Node: AS200 Process name: "NOPRIV_USER" Authorized privileges: NETMBX TMPMBX Process privileges: NETMBX may create network device TMPMBX may create temporary mailbox Process rights: DEFAULT resource INTERACTIVE LOCAL System rights: SYS$NODE_AS200 Soft CPU Affinity: off $ RUN SYS$SYSDEVICE:[DEFCON]LOADDEMO $ INSTALL INSTALL> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX $ $ SHOW PROCESS/PRIVILEGES 19-AUG-2008 16:24:48.37 User: NOPRIV_USER Process ID: 00000245 Node: AS200 Process name: "NOPRIV_USER" Authorized privileges: ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD Process privileges: NETMBX may create network device TMPMBX may create temporary mailbox Process rights: DEFAULT resource INTERACTIVE LOCAL System rights: SYS$NODE_AS200 Soft CPU Affinity: off $ SET PROCESS/PRIVILEGES=ALL $ SHOW PROCESS/PRIVILEGES 19-AUG-2008 16:25:45.60 User: NOPRIV_USER Process ID: 00000245 Node: AS200 Process name: "NOPRIV_USER" Authorized privileges: ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD Process privileges: ACNT may suppress accounting messages ALLSPOOL may allocate spooled device ALTPRI may set any priority value AUDIT may direct audit to system security audit log BUGCHK may make bug check log entries BYPASS may bypass all object access controls CMEXEC may change mode to exec CMKRNL may change mode to kernel DIAGNOSE may diagnose devices DOWNGRADE may downgrade object secrecy EXQUOTA may exceed disk quota GROUP may affect other processes in same group GRPNAM may insert in group logical name table GRPPRV may access group objects via system protection IMPERSONATE may impersonate another user IMPORT may set classification for unlabeled object LOG_IO may do logical i/o MOUNT may execute mount acp function NETMBX may create network device OPER may perform operator functions PFNMAP may map to specific physical pages PHY_IO may do physical i/o PRMCEB may create permanent common event clusters PRMGBL may create permanent global sections PRMMBX may create permanent mailbox PSWAPM may change process swap mode READALL may read anything as the owner SECURITY may perform security administration functions SETPRV may set any privilege bit SHARE may assign channels to non-shared devices SHMEM may create/delete objects in shared memory SYSGBL may create system wide global sections SYSLCK may lock system wide resources SYSNAM may insert in system logical name table SYSPRV may access objects via system protection TMPMBX may create temporary mailbox UPGRADE may upgrade object integrity VOLPRO may override volume protection WORLD may affect other processes in the world Process rights: DEFAULT resource INTERACTIVE LOCAL System rights: SYS$NODE_AS200 Soft CPU Affinity: off $ The code for this is 90(16), 144(10) bytes! I adhered to the calling standard. There are some null quadwords in there (3) to maintain the proper alignment too. It does NOT take much code to implement this. Also, I was able to do this "silently", unlike those original demos. This could be _easily_ weaponized. -- 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: Tue, 19 Aug 2008 22:18:10 GMT From: gerry77@no.spam.mail.com Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Tue, 19 Aug 2008 20:43:14 GMT, VAXman- @SendSpamHere.ORG wrote: > Hein's patch for this vulnerability is making its rounds and reports are > that HP has one to be made available for public consumption shortly Do you think HP will provide a patch even for OpenVMS VAX? What's the actual official status for OpenVMS VAX? Unsupported? I'm almost sure the answer will be negative, and I'm most concerned about that. There are lots of VAXen out there, many offering guest access too. Do you think someone (you?) will be able and will be willing to create a little binary patch for those systems too, like the one made by Hein for Alpha? G. ------------------------------ Date: Tue, 19 Aug 2008 22:29:51 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E5B2.0838EBEC@SendSpamHere.ORG> In article , gerry77@no.spam.mail.com writes: >On Tue, 19 Aug 2008 20:43:14 GMT, VAXman- @SendSpamHere.ORG wrote: > >> Hein's patch for this vulnerability is making its rounds and reports are >> that HP has one to be made available for public consumption shortly > >Do you think HP will provide a patch even for OpenVMS VAX? What's the actual >official status for OpenVMS VAX? Unsupported? > >I'm almost sure the answer will be negative, and I'm most concerned about >that. There are lots of VAXen out there, many offering guest access too. Do >you think someone (you?) will be able and will be willing to create a little >binary patch for those systems too, like the one made by Hein for Alpha? If HP doesn't, I will or Hein or anyone else who understands where the problem resides may do one. -- 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: Tue, 19 Aug 2008 22:32:47 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: gerry77@no.spam.mail.com wrote: > What's the actual > official status for OpenVMS VAX? Unsupported? http://h71000.www7.hp.com/openvms/openvms_supportchart.html ------------------------------ Date: Tue, 19 Aug 2008 22:47:49 GMT From: gerry77@no.spam.mail.com Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <7nima493jp4644k7lnvkar20kmtfl4tnum@4ax.com> On Tue, 19 Aug 2008 22:32:47 GMT, Jan-Erik Söderholm wrote: > > What's the actual official status for OpenVMS VAX? Unsupported? > > http://h71000.www7.hp.com/openvms/openvms_supportchart.html Thanks! Actually I spotted that URL just 30 seconds after posting. :-P BTW, what's the exact meaning of "previous version support"? In such a case like the one we are speaking about, HP should/would resolve the issue with a patch made available only to those customer paying for "special" PVS support or free to anyone via the usual FTP site? G. ------------------------------ Date: Tue, 19 Aug 2008 17:06:56 -0600 From: "Michael D. Ober" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: "Bob Koehler" wrote in message news:42ZjjxaOX+KG@eisner.encompasserve.org... > In article <8660a3a10808181315y2cfd98ebx3187c8d6a5688f24@mail.gmail.com>, > "William Webb" writes: >> >> "Anybody who says his system is bulletproof is either a liar or stupid." >> >> Winn Schwartau > > Oh, come on. I have one of those. It's siting in the basement, > turned off and unplugged. > > Yes, but can it stop a bullet? ------------------------------ Date: Tue, 19 Aug 2008 23:58:36 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E5BE.6E629753@SendSpamHere.ORG> In article , "Michael D. Ober" writes: >"Bob Koehler" wrote in message >news:42ZjjxaOX+KG@eisner.encompasserve.org... >> In article <8660a3a10808181315y2cfd98ebx3187c8d6a5688f24@mail.gmail.com>, >> "William Webb" writes: >>> >>> "Anybody who says his system is bulletproof is either a liar or stupid." >>> >>> Winn Schwartau >> >> Oh, come on. I have one of those. It's siting in the basement, >> turned off and unplugged. >> >> > >Yes, but can it stop a bullet? His basement... probably. -- 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: Tue, 19 Aug 2008 20:30:08 -0400 From: "Richard B. Gilbert" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <2K-dnU-WyogN-DbVnZ2dnUVZ_sbinZ2d@comcast.com> gerry77@no.spam.mail.com wrote: > On Tue, 19 Aug 2008 22:32:47 GMT, Jan-Erik Söderholm > wrote: > >>> What's the actual official status for OpenVMS VAX? Unsupported? >> http://h71000.www7.hp.com/openvms/openvms_supportchart.html > > Thanks! Actually I spotted that URL just 30 seconds after posting. :-P > > BTW, what's the exact meaning of "previous version support"? In such a case > like the one we are speaking about, HP should/would resolve the issue with a > patch made available only to those customer paying for "special" PVS support > or free to anyone via the usual FTP site? > > G. > Previous/Prior version support is generally support offered at extra cost for an older version of the software. If Vn.m is current, Vn.m-1 is a prior version. You get a limited period during which both Vn.m and Vn.m-1 are supported. After that brief period, Vn.m-1 will be supported only at extra cost. The older it gets, the more it costs. If you are willing and able to pay for it, you could probably get prior version support for V5.5-2. You should expect to pay something like $750,000 to $1,000,000/year for 24x7x365 support. With holidays, sick days and vacation a minimum of five people would be required to man the phone. The people supporting you would need a system that would boot the software being supported, etc. Actually, I'm probably underestimating the cost because it takes not only people to answer the phone but also developers to provide patches. You would have to want very badly to run a version that old to be willing to bear the cost. ------------------------------ Date: Tue, 19 Aug 2008 18:16:14 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com> On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: > Hein's patch for this vulnerability is making its rounds and reports are > that HP has one to be made available for public consumption shortly, I'd > just like to offer this: > > Username: NOPRIV_USER > Password: > > Welcome to the OpenVMS AXP Operating System, version V8.3 > > Last interactive login on Tuesday, 19-AUG-2008 16:11:08.58 > > $ SET TERMINAL/UNKNOWN > $ SHOW PROCESS/PRIVILEGES > > 19-AUG-2008 16:20:58.13 User: NOPRIV_USER Process ID: 00000245 > Node: AS200 Process name: "NOPRIV_USER" > > Authorized privileges: > NETMBX TMPMBX > > Process privileges: > NETMBX may create network device > TMPMBX may create temporary mailbox > > Process rights: > DEFAULT resource > INTERACTIVE > LOCAL > > System rights: > SYS$NODE_AS200 > > Soft CPU Affinity: off > $ RUN SYS$SYSDEVICE:[DEFCON]LOADDEMO > $ INSTALL > INSTALL> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $ $ SHOW PROCESS/PRIVILEGES > > 19-AUG-2008 16:24:48.37 User: NOPRIV_USER Process ID: 00000245 > Node: AS200 Process name: "NOPRIV_USER" > > Authorized privileges: > ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS > CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP > GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT > NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL > PRMMBX PSWAPM READALL SECURITY SETPRV SHARE > SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX > UPGRADE VOLPRO WORLD > > Process privileges: > NETMBX may create network device > TMPMBX may create temporary mailbox > > Process rights: > DEFAULT resource > INTERACTIVE > LOCAL > > System rights: > SYS$NODE_AS200 > > Soft CPU Affinity: off > $ SET PROCESS/PRIVILEGES=ALL > $ SHOW PROCESS/PRIVILEGES > > 19-AUG-2008 16:25:45.60 User: NOPRIV_USER Process ID: 00000245 > Node: AS200 Process name: "NOPRIV_USER" > > Authorized privileges: > ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS > CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GROUP > GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOUNT > NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL > PRMMBX PSWAPM READALL SECURITY SETPRV SHARE > SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX > UPGRADE VOLPRO WORLD > > Process privileges: > ACNT may suppress accounting messages > ALLSPOOL may allocate spooled device > ALTPRI may set any priority value > AUDIT may direct audit to system security audit log > BUGCHK may make bug check log entries > BYPASS may bypass all object access controls > CMEXEC may change mode to exec > CMKRNL may change mode to kernel > DIAGNOSE may diagnose devices > DOWNGRADE may downgrade object secrecy > EXQUOTA may exceed disk quota > GROUP may affect other processes in same group > GRPNAM may insert in group logical name table > GRPPRV may access group objects via system protection > IMPERSONATE may impersonate another user > IMPORT may set classification for unlabeled object > LOG_IO may do logical i/o > MOUNT may execute mount acp function > NETMBX may create network device > OPER may perform operator functions > PFNMAP may map to specific physical pages > PHY_IO may do physical i/o > PRMCEB may create permanent common event clusters > PRMGBL may create permanent global sections > PRMMBX may create permanent mailbox > PSWAPM may change process swap mode > READALL may read anything as the owner > SECURITY may perform security administration functions > SETPRV may set any privilege bit > SHARE may assign channels to non-shared devices > SHMEM may create/delete objects in shared memory > SYSGBL may create system wide global sections > SYSLCK may lock system wide resources > SYSNAM may insert in system logical name table > SYSPRV may access objects via system protection > TMPMBX may create temporary mailbox > UPGRADE may upgrade object integrity > VOLPRO may override volume protection > WORLD may affect other processes in the world > > Process rights: > DEFAULT resource > INTERACTIVE > LOCAL > > System rights: > SYS$NODE_AS200 > > Soft CPU Affinity: off > $ > > The code for this is 90(16), 144(10) bytes! I adhered to the calling > standard. There are some null quadwords in there (3) to maintain the > proper alignment too. It does NOT take much code to implement this. > Also, I was able to do this "silently", unlike those original demos. > This could be _easily_ weaponized. > > -- > 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. Congrats to a nice exploit! Seems like you got a nice solution there, but how do you enter the return address (we use this terminology for the address that you branch to), is that done automatically using a pseudo terminal or do you type it in manually using the keyboard? If you want to weaponize it (if so, why?) you should really look into a fully automated exploit that works over all releases and takes full advantage over the vulnerability. When it comes to writing exploits you can divide the development roughly in two parts: 1) Controlling the return address (or the address that you branch too) 2) Execute code that does something useful But before even starting to write any exploit, you have to determine IF the bug actually is exploitable. That is one of the largest question marks for any vulnerability hunter. Developers and vendors often incorrectly claim that a certain bug is not exploitable, hopefully because of lack of knowledge in most cases. Take a look at format string vulnerabilities for example, there was a lot of "experts" telling that this kind of bug could not be used for anything but crashing processes but all that had to be done to learn how to take control of the execution flow was to read the manual and learn about the %n command, now how sick is that?! If you don't know what we are talking about, you can read the excellent Teso paper on the subject, we did that our selfs back in 2k. Depending on the vulnerability, step 1 is often a bit tricky on most OS's these days since the low hanging fruit like simple overwrites of a function pointer or a return/branch address is pretty much gone in interesting software. This is obviously not the case in OpenVMS. :) Take a look at heap corruption bugs for example, those can be a real mess when it comes to fully controlling the return/branch address. When the return/branch address is fully controlled, the vulnerability is "stable" in the sense that the execution flow is under total control. But in many vulnerabilities you also have to "clean up your mess" and patch/restore the data that was overwritten in order to take full control of the return/branch address to avoid crashes later on. This is not the case with this vulnerability since the return/branch address is fully controlled from start which makes it trivial to exploit. It can be really hard though, especially when you are writing exploits for kernel based vulnerabilities since one single mistake will crash the whole system, and there is a lot of data structures to keep track of. At this step the most of the work (90%) is done in most cases, like in this case. Since we do not know much/anything about OpenVMS we approached step 2 in the same way that we do on other OS's, we wrote so called shellcode (since we had none to use from previous research), or let us call it payload as someone suggested earlier (compiled code written in assembly for the target architecture which is position independent and often NULL free, but there are methods to write architecture independed shellcode too!) and started to investigate ways of injecting it into the process. Also, when writing shellcode or payloads, you should write it in a way so that it easily can be reused for future exploits, common coding practice though. We often use a simple shellcode/payload for testing as a first step in an exploit (such as code that creates an empty file) just to verify that it all works before we use something "real". When we started to write the shellcode/payload we looked at many of the different system services available on OpenVMS, unfortunately, many of the interesting ones requires certain privileges to be called, except for the create process system service which executed a program with the current privileges inherited. The create process system service (is that the right terminology, or can it be called system call under VMS as well?) was perfect since it can be used for any kind of privilege escalation bug (for example, your exploit does not work against the TELNET client that only provide OPER privileges so it does not fully take advantage of the vulnerability), and even in remote exploits without requirements of a terminal etc. As the next step, we wanted to know what kind of privileges the process have when we jumped/branched to our code. Just because the program is installed with higher privileges does not mean that they exist when the vulnerability is triggered. The most time consuming part when writing the payload/shellcode was to find the index of the create process system service on Alpha, since the debugger did not allow us to break on a certain instruction. like on VAX (if there is a way to easily find the system call index, we will be happy to take part of that information). We single stepped (christer did the most work here actually, he knows his single stepping by now :) the execution of a small program until the index number was revealed. At this point we wrote the FILE.EXE tool, which simply wrote the privileges of the current process to a file on disk (PRIVS.TXT) since the current implementation of the *reusable* shellcode/payload did not support writing to the default output stream (SYS$OUTPUT). This was very handy, since we could examine all kind of bugs using the shellcode/payload together with FILE.EXE to learn what privileges that could be escalated. When the shellcode/payload was written, we injected it into a VMS logical and jumped/branched there to execute it. At this point, when we executed the shellcode/payload that in turn executed the FILE.EXE tool we got the PoC exploit finished. A PoC exploit is a Proof of Concept exploit that demostrates the vulnerability in such a way that most people can understand that the bug actually can be exploited (one of the largest question marks, remember). It does not really matter if everybody understand it, the most important thing is that the vendor understands the problem so that a patch can be created and released. So we decided not to develop the exploit any further since it was enough to demonstrate the problem. Now when you have written your first (trivial) exploit, or actually what you did was to jump/branch to your own routine using a vulnerability that someone else found. The technique you use is interesting, you load code into a privileged process using a documented user invokable mechanism. Can you also wrap existing routines using this method, like with LD_PRELOAD in *NIX? However, we encourage you to look for more vulnerabilities (there are more for sure) and write (PoC) exploits for them as well, to help secure the system. We will be happy to help out trying to determine if a certain bug is exploitable or not, that goes for anyone that want to do bug hunting. Perhaps we could combine your knowledge of OpenVMS with our experience of writing exploits to accomplish something. We hope, that we, with this post, have cleared all the question marks about our process for proofing the vulnerabilities that we found. ------------------------------ Date: Tue, 19 Aug 2008 21:16:56 -0400 From: "William Webb" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <8660a3a10808191816k31d8cbe1scf9e7cbbad130c98@mail.gmail.com> On Tue, Aug 19, 2008 at 10:56 AM, Bob Koehler wrote: > In article <8660a3a10808181315y2cfd98ebx3187c8d6a5688f24@mail.gmail.com>, "William Webb" writes: >> >> "Anybody who says his system is bulletproof is either a liar or stupid." >> >> Winn Schwartau > > Oh, come on. I have one of those. It's siting in the basement, > turned off and unplugged. > > Reminds me of a site I once hit: Description was something like "Ultimate Firewall". Link took you to a jpeg of a cable cutter poised to strike. WWWebb ------------------------------ Date: Tue, 19 Aug 2008 20:20:35 -0700 From: "Tom Linden" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Tue, 19 Aug 2008 18:16:14 -0700, wrote: > On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: >> Hein's patch for this vulnerability is making its rounds and reports = are >> that HP has one to be made available for public consumption shortly, = I'd >> just like to offer this: >> >> Username: NOPRIV_USER >> Password: >> >> Welcome to the OpenVMS AXP Operating System, version V8.3 >> >> Last interactive login on Tuesday, 19-AUG-2008 16:11:08.58 >> >> $ SET TERMINAL/UNKNOWN >> $ SHOW PROCESS/PRIVILEGES >> >> 19-AUG-2008 16:20:58.13 User: NOPRIV_USER Process ID: 000002= 45 >> Node: AS200 Process name: = >> "NOPRIV_USER" >> >> Authorized privileges: >> NETMBX TMPMBX >> >> Process privileges: >> NETMBX may create network device >> TMPMBX may create temporary mailbox >> >> Process rights: >> DEFAULT resource >> INTERACTIVE >> LOCAL >> >> System rights: >> SYS$NODE_AS200 >> >> Soft CPU Affinity: off >> $ RUN SYS$SYSDEVICE:[DEFCON]LOADDEMO >> $ INSTALL >> INSTALL> = >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> $ $ SHOW PROCESS/PRIVILEGES >> >> 19-AUG-2008 16:24:48.37 User: NOPRIV_USER Process ID: 000002= 45 >> Node: AS200 Process name: = >> "NOPRIV_USER" >> >> Authorized privileges: >> ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYP= ASS >> CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GRO= UP >> GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOU= NT >> NETMBX OPER PFNMAP PHY_IO PRMCEB PRM= GBL >> PRMMBX PSWAPM READALL SECURITY SETPRV SHA= RE >> SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMP= MBX >> UPGRADE VOLPRO WORLD >> >> Process privileges: >> NETMBX may create network device >> TMPMBX may create temporary mailbox >> >> Process rights: >> DEFAULT resource >> INTERACTIVE >> LOCAL >> >> System rights: >> SYS$NODE_AS200 >> >> Soft CPU Affinity: off >> $ SET PROCESS/PRIVILEGES=3DALL >> $ SHOW PROCESS/PRIVILEGES >> >> 19-AUG-2008 16:25:45.60 User: NOPRIV_USER Process ID: 000002= 45 >> Node: AS200 Process name: = >> "NOPRIV_USER" >> >> Authorized privileges: >> ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYP= ASS >> CMEXEC CMKRNL DIAGNOSE DOWNGRADE EXQUOTA GRO= UP >> GRPNAM GRPPRV IMPERSONATE IMPORT LOG_IO MOU= NT >> NETMBX OPER PFNMAP PHY_IO PRMCEB PRM= GBL >> PRMMBX PSWAPM READALL SECURITY SETPRV SHA= RE >> SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMP= MBX >> UPGRADE VOLPRO WORLD >> >> Process privileges: >> ACNT may suppress accounting messages >> ALLSPOOL may allocate spooled device >> ALTPRI may set any priority value >> AUDIT may direct audit to system security audit log >> BUGCHK may make bug check log entries >> BYPASS may bypass all object access controls >> CMEXEC may change mode to exec >> CMKRNL may change mode to kernel >> DIAGNOSE may diagnose devices >> DOWNGRADE may downgrade object secrecy >> EXQUOTA may exceed disk quota >> GROUP may affect other processes in same group >> GRPNAM may insert in group logical name table >> GRPPRV may access group objects via system protection >> IMPERSONATE may impersonate another user >> IMPORT may set classification for unlabeled object >> LOG_IO may do logical i/o >> MOUNT may execute mount acp function >> NETMBX may create network device >> OPER may perform operator functions >> PFNMAP may map to specific physical pages >> PHY_IO may do physical i/o >> PRMCEB may create permanent common event clusters >> PRMGBL may create permanent global sections >> PRMMBX may create permanent mailbox >> PSWAPM may change process swap mode >> READALL may read anything as the owner >> SECURITY may perform security administration functions >> SETPRV may set any privilege bit >> SHARE may assign channels to non-shared devices >> SHMEM may create/delete objects in shared memory >> SYSGBL may create system wide global sections >> SYSLCK may lock system wide resources >> SYSNAM may insert in system logical name table >> SYSPRV may access objects via system protection >> TMPMBX may create temporary mailbox >> UPGRADE may upgrade object integrity >> VOLPRO may override volume protection >> WORLD may affect other processes in the world >> >> Process rights: >> DEFAULT resource >> INTERACTIVE >> LOCAL >> >> System rights: >> SYS$NODE_AS200 >> >> Soft CPU Affinity: off >> $ >> >> The code for this is 90(16), 144(10) bytes! I adhered to the calling= >> standard. There are some null quadwords in there (3) to maintain the= >> proper alignment too. It does NOT take much code to implement this. >> Also, I was able to do this "silently", unlike those original demos. >> This could be _easily_ weaponized. >> >> -- >> 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 b= e. = >> (NJSC) >> >> Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet articl= e = >> outside >> of usenet _must_ include its contents in its entirety including this = = >> copyright >> notice, disclaimer and quotations. > > Congrats to a nice exploit! > Seems like you got a nice solution there, but how do you enter the > return address (we use this terminology for the address that you > branch to), > is that done automatically using a pseudo terminal or do you type it > in manually using the keyboard? > If you want to weaponize it (if so, why?) you should really look into > a fully automated exploit that works over all releases and takes full > advantage over the vulnerability. > > When it comes to writing exploits you can divide the development > roughly in two parts: > > 1) Controlling the return address (or the address that you branch too)= > 2) Execute code that does something useful > > But before even starting to write any exploit, you have to determine > IF the bug actually is exploitable. That is one of the largest > question marks for any vulnerability hunter. Developers and vendors > often incorrectly claim that a certain bug is not exploitable, > hopefully because of lack of knowledge in most cases. Take a look at > format string vulnerabilities for example, there was a lot of > "experts" telling that this kind of bug could not be used for anything= > but crashing processes but all that had to be done to learn how to > take control of the execution flow was to read the manual and learn > about the %n command, now how sick is that?! If you don't know what we= > are talking about, you can read the excellent Teso paper on the > subject, we did that our selfs back in 2k. > > Depending on the vulnerability, step 1 is often a bit tricky on most > OS's these days since the low hanging fruit like simple overwrites of > a function pointer or a return/branch address is pretty much gone in > interesting software. > This is obviously not the case in OpenVMS. :) Take a look at heap > corruption bugs for example, those can be a real mess when it comes to= > fully controlling the return/branch address. > When the return/branch address is fully controlled, the vulnerability > is "stable" in the sense that the execution flow is under total > control. > But in many vulnerabilities you also have to "clean up your mess" and > patch/restore the data that was overwritten in order to take full > control of the return/branch address to avoid crashes later on. > This is not the case with this vulnerability since the return/branch > address is fully controlled from start which makes it trivial to > exploit. > It can be really hard though, especially when you are writing exploits= > for kernel based vulnerabilities since one single mistake will crash > the whole system, and there is a lot of data structures to keep track > of. > At this step the most of the work (90%) is done in most cases, like in= > this case. > > Since we do not know much/anything about OpenVMS we approached step 2 > in the same way that we do on other OS's, we wrote so called shellcode= > (since we had none to use from previous research), or let us call it > payload as someone suggested earlier (compiled code written in > assembly for the target architecture which is position independent and= > often NULL free, but there are methods to write architecture > independed shellcode too!) and started to investigate ways of > injecting it into the process. Also, when writing shellcode or > payloads, you should write it in a way so that it easily can be reused= > for future exploits, common coding practice though. > > We often use a simple shellcode/payload for testing as a first step in= > an exploit (such as code that creates an empty file) just to verify > that it all works before we use something "real". > When we started to write the shellcode/payload we looked at many of > the different system services available on OpenVMS, unfortunately, > many of the interesting ones requires certain privileges to be called,= > except for the create process system service which executed a program > with the current privileges inherited. > > The create process system service (is that the right terminology, or > can it be called system call under VMS as well?) was perfect since it > can be used for any kind of privilege escalation bug (for example, > your exploit does not work against the TELNET client that only provide= > OPER privileges so it does not fully take advantage of the > vulnerability), and even in remote exploits without requirements of a > terminal etc. As the next step, we wanted to know what kind of > privileges the process have when we jumped/branched to our code. Just > because the program is installed with higher privileges does not mean > that they exist when the vulnerability is triggered. > > The most time consuming part when writing the payload/shellcode was to= > find the index of the create process system service on Alpha, since > the debugger did not allow us to break on a certain instruction. like > on VAX (if there is a way to easily find the system call index, we > will be happy to take part of that information). We single stepped > (christer did the most work here actually, he knows his single > stepping by now :) the execution of a small program until the index > number was revealed. > At this point we wrote the FILE.EXE tool, which simply wrote the > privileges of the current process to a file on disk (PRIVS.TXT) since > the current implementation of the *reusable* shellcode/payload did not= > support writing to the default output stream (SYS$OUTPUT). This was > very handy, since we could examine all kind of bugs using the > shellcode/payload together with FILE.EXE to learn what privileges that= > could be escalated. > > When the shellcode/payload was written, we injected it into a VMS > logical and jumped/branched there to execute it. > At this point, when we executed the shellcode/payload that in turn > executed the FILE.EXE tool we got the PoC exploit finished. > A PoC exploit is a Proof of Concept exploit that demostrates the > vulnerability in such a way that most people can understand that the > bug actually can be exploited (one of the largest question marks, > remember). > It does not really matter if everybody understand it, the most > important thing is that the vendor understands the problem so that a > patch can be created and released. > So we decided not to develop the exploit any further since it was > enough to demonstrate the problem. > > Now when you have written your first (trivial) exploit, or actually > what you did was to jump/branch to your own routine using a > vulnerability that someone else found. > The technique you use is interesting, you load code into a privileged > process using a documented user invokable mechanism. Can you also wrap= > existing routines using this method, like with LD_PRELOAD in *NIX? > However, we encourage you to look for more vulnerabilities (there are > more for sure) and write (PoC) exploits for them as well, to help > secure the system. > We will be happy to help out trying to determine if a certain bug is > exploitable or not, that goes for anyone that want to do bug hunting. > Perhaps we could combine your knowledge of OpenVMS with our experience= > of writing exploits to accomplish something. > > We hope, that we, with this post, have cleared all the question marks > about our process for proofing the vulnerabilities that we found. I have to ask, why you got involved with this, what was in it for you? I am too cynical to accept altruism or kicks. good work, never-the-less= . -- = PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 19 Aug 2008 14:55:58 -0400 From: JF Mezei Subject: Re: Disk remains in HostUnavailable for a very long time Message-ID: <48ab1834$0$1817$c3e8da3@news.astraweb.com> Michael Moroney wrote: > This status is normal if communication with the remote MSCP server is > down, until the last status you gave where it was shown as mounted/remote > mount. Not sure why it didn't show up as available quicker, other than > the periodic MSCP "I'm available" message is a datagram which doesn't have > guaranteed delivery. Are there SYSGEN parameters on VAX (7.3) or on Alpha that might result in the Alpha realising that the VAX's disks are available again ? ------------------------------ Date: Tue, 19 Aug 2008 15:00:11 -0400 From: JF Mezei Subject: Re: DS10L power supply mystery Message-ID: <48ab1933$0$1829$c3e8da3@news.astraweb.com> Michael Moroney wrote: > Nowadays power supplies usually have less crude protection logic, but > often they require manual intervention such as removing power to reset > them. But power was completely out for a few hours last night... And because I had switched up the breaker for that room, the alpha would not have seen transients when the power utility re-energized the neighbourhoud. I waited over half an hour before putting the breaker back to "ON". So you'd think a few hours without power would have reset the power supply :-) Would you guys suggest I perform additional tests ? (cutting poower abruptly and then applying it back some minutes later) ? My concern is that if the power supply is "weak", such tests would weaken it more. ------------------------------ Date: Tue, 19 Aug 2008 16:52:52 -0400 From: John Sauter Subject: Re: DS10L power supply mystery Message-ID: <8M-dnfBmGec4rzbVnZ2dnUVZ_hOdnZ2d@comcast.com> JF Mezei wrote: > Michael Moroney wrote: > >> Nowadays power supplies usually have less crude protection logic, but >> often they require manual intervention such as removing power to reset >> them. > > But power was completely out for a few hours last night... > > And because I had switched up the breaker for that room, the alpha would > not have seen transients when the power utility re-energized the > neighbourhoud. I waited over half an hour before putting the breaker > back to "ON". > > So you'd think a few hours without power would have reset the power > supply :-) > > Would you guys suggest I perform additional tests ? (cutting poower > abruptly and then applying it back some minutes later) ? My concern is > that if the power supply is "weak", such tests would weaken it more. I don't know how to reliably crowbar a power supply, so I can't recommend a useful test. However, in my experience, the crowbar condition will not reset until good power is applied and then removed. No amount of waiting while the power is off will reset it. It is by no means certain that the power supply is ready to fail. I have seen power supplies run fine for years after crowbarring. John Sauter (John_Sauter@systemeyescomputerstore.com) ------------------------------ Date: Tue, 19 Aug 2008 21:13:53 -0400 From: "William Webb" Subject: Re: DS10L power supply mystery Message-ID: <8660a3a10808191813o4154b9e7rf840bb7a4220c696@mail.gmail.com> On Tue, Aug 19, 2008 at 3:56 AM, JF Mezei wrote: > Power failure. > DS10L has no choice but to shutdown :-( > > I switch off the breaker for the machine. > After power has returned, I power the breaker back on. > > the DSL10L powers back on, fans are working, gree light in fron is on. > But no output on (serial) console. Nothing, nada. No RMC either. > > Using the "power" button, I can power off and on the DS10L to the same > effect. > > In the back, the air coming out of the power supply is warm, but air > coming out of the rest is cool and at a lesser rate. > > Repeat cycle, same thing. > > The trick is to physically pull the power cord from back of the DS10L, > wait a second or 3 and put it back in. At that point, the unit powers > back on, I can hear the 2 disks spinning up, air flow in the back is > greater and getting warmer quickly, and the opower up sequence is > displayed on the console, machine boots normally. > > Can anyone explain this ? > > What would be the difference between unplugging the unit and using a > large breaker to feed power back to it ? > Hi, jf probably cheaper to order an entire DS10L from our favorite vendor in Savannah/Tybee Island than it would be to find a power supply. WWWebb ------------------------------ Date: Tue, 19 Aug 2008 22:49:15 -0500 From: patrick jankowiak Subject: Re: DS10L power supply mystery Message-ID: William Webb wrote: > On Tue, Aug 19, 2008 at 3:56 AM, JF Mezei wrote: >> Power failure. >> DS10L has no choice but to shutdown :-( >> >> I switch off the breaker for the machine. >> After power has returned, I power the breaker back on. >> >> the DSL10L powers back on, fans are working, gree light in fron is on. >> But no output on (serial) console. Nothing, nada. No RMC either. >> >> Using the "power" button, I can power off and on the DS10L to the same >> effect. >> >> In the back, the air coming out of the power supply is warm, but air >> coming out of the rest is cool and at a lesser rate. >> >> Repeat cycle, same thing. >> >> The trick is to physically pull the power cord from back of the DS10L, >> wait a second or 3 and put it back in. At that point, the unit powers >> back on, I can hear the 2 disks spinning up, air flow in the back is >> greater and getting warmer quickly, and the opower up sequence is >> displayed on the console, machine boots normally. >> >> Can anyone explain this ? >> >> What would be the difference between unplugging the unit and using a >> large breaker to feed power back to it ? >> > > Hi, jf > > probably cheaper to order an entire DS10L from our favorite vendor in > Savannah/Tybee Island than it would be to find a power supply. > > WWWebb That supply probably does not use a crowbard (SCR->ON). It probably stops drive to a switching transistor. There is likely an IC (or several) that has overvoltage, undervoltage, and overcurrent sensing and triggering any of these will stop it. It may also have a smaller standby type of switching supply internally, to keep the switching controller live, even if the main switcher (power factor controller) or one of the subordinate switchers is shut down. Repairing old/questionable switching power supplies is interesting and may produce spectacular results if something has been overlooked. One thing to check is using an oscilloscope, look for noise on each DC line from the switcher. They should have no more than about 50mV peak noise. A bad filter capacitor on any DC voltage can cause much noise to the point of causing shutdowns and even subtle things like unexplained errors or crashes. An ESR (equivalent series resistance) meter can be used to check the capacitors individually and a high ESR is a sure sign of a bad cap. I had a DG Nova 1200 that was given to me because it had blown most of the foil off all of the circuit boards and many chunks out of the couple hundred 14-pin DIP ICs during the previous owner's attempt to repair the switching power supply. In the dim time, switchers were new and cantankerous and few people understood them. It must have taken several seconds for the machine to die that horrible death and the poppencorken mit spitzensparken would have been enough to clear the room of any lurking veeblefesters. PJ ------------------------------ Date: Tue, 19 Aug 2008 11:28:21 -0700 (PDT) From: vaxdecman@aol.com Subject: Re: Storage Shelves for FREE Message-ID: On Aug 18, 4:17=A0pm, "Tom Linden" wrote: > Have 4 Blue BA356 each with one Power Suply, one personality module and 7 > drives. =A0(RZ1DD) > > 3 grey BA350 No personality modules in these with RZ28 drives > > 1. =A03 Power supplie 3 drives > 2. =A03 Power Supplies 5 drives > 3. =A02 Power Supplies 5 drives > > You pay for shipping, from 93953 > > -- > PL/I for OpenVMSwww.kednos.com Hello, any takers? Is everything listed in working condition? Thanks. ------------------------------ Date: Tue, 19 Aug 2008 16:07:37 -0700 From: "Tom Linden" Subject: Re: Storage Shelves for FREE Message-ID: On Tue, 19 Aug 2008 11:28:21 -0700, wrote: > On Aug 18, 4:17 pm, "Tom Linden" wrote: >> Have 4 Blue BA356 each with one Power Suply, one personality module and >> 7 >> drives.  (RZ1DD) >> >> 3 grey BA350 No personality modules in these with RZ28 drives >> >> 1.  3 Power supplie 3 drives >> 2.  3 Power Supplies 5 drives >> 3.  2 Power Supplies 5 drives >> >> You pay for shipping, from 93953 >> >> -- >> PL/I for OpenVMSwww.kednos.com > > Hello, any takers? Is everything listed in working condition? Thanks. Just mail off line, remove the obvious from the address -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 19 Aug 2008 11:44:30 -0700 (PDT) From: vaxdecman@aol.com Subject: Re: What to do now with a DEC Server 3000? Message-ID: <53b6f9d3-c286-4b69-b32b-0d9c9bf38135@t54g2000hsg.googlegroups.com> On Aug 13, 2:28=A0pm, "***** charles" wrote: > "Steven M. Schweda" wrote in messagenews:08081308321= 926_20200492@antinode.info... > > > > > > > From: "***** charles" > > >> Hi, this seems to be the right group. =A0I came across a DEC Server 30= 00 > > > =A0 What does it _actually_ say on the front? =A0Sounds like one of the > > "white-box" systems intended for Windows NT (only). > > >> FR-K7F4W-AB with a 500MHz alpha chip and one stick of 128M of ram and = I > >> don't know how big the hard drive is yet. =A0I have fired it up, white > >> letters > >> on a blue background and the final prompt is >>>. =A0I know a bit abou= t a > >> lot > >> of architectures but this is my first alpha so I am stumped. =A0The gu= y > >> that I > >> got it from said it would run VMS but I don't know how to get it that = far > >> if > >> that is true. =A0Any other ideas? > > > =A0 =A0 =A0http://h71000.www7.hp.com/index.html > > =A0 =A0 =A0http://h18002.www1.hp.com/alphaserver/ > > =A0 =A0 =A0http://h18002.www1.hp.com/alphaserver/archive/ > > =A0 =A0 =A0[...] > > > =A0 >>>help > > =A0 >>>boot > > > =A0 =A0 =A0http://hoffmanlabs.org/vmsfaq/ > > >> =A0 I understand that this machine will go to > >> 1G of ram (2 sitcks of 512M each). =A0Anyone know where I could get so= me of > >> this cheap? > > > =A0 Ebay? > > Well, after lots of surfing I was able to determine the following: > > 1. on the front it says DIGITAL Server 3000 and on the back > =A0 =A0 the model number is FR-K7F4W-AB =A0I haven't been able to > =A0 =A0 determine if this is supposed to be NT only or not. =A0I am > =A0 =A0 downloading a Debian Linux install networking cd. =A0I did try > =A0 =A0 the boot command to the scsi controller and it booted to > =A0 =A0 =A0NetBSD which will be replaced as soon as I can burn the > =A0 =A0 =A0Debian cd. =A0From further research I am thinking that this > =A0 =A0 =A0box might be a 3305 but it does not say that anywhere. =A0It > =A0 =A0 =A0does have a 500MHz alpha chip in it 21164A-2. =A0The > =A0 =A0 =A0prompt >>> should indicate that the box is not the NT only > =A0 =A0 =A0box I have been reading about. > =A0 =A0 =A0show version gives: > =A0 =A0 =A0 V5.4-U3 =A0 March 24 1999 =A012:39:17 > =A0 =A0 =A0 show pal gives: > =A0 =A0 =A0 =A0VMS =A0PALcode =A0V1.20-3 > =A0 =A0 =A0 =A0 OSF =A0PALcode =A0V1.22-5 > =A0 =A0 =A0 =A0show config gives: > =A0 =A0 =A0 =A0 slot5 QLogic ISP1020 pka0.7.0.5.0 =A0scsi bus id 7 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 dka100.1.0.5.0 Quantum XP34550J > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 dka400.4.0.5.0 RRD46 scsi cd-rom > =A0 =A0 =A0 =A0 =A0slot6 S3 Trio 64/Trio32 > =A0 =A0 =A0 =A0 =A0slot7 Intel 82375 =A0 =A0 =A0 =A0 =A0Bridge to Bus1, E= ISA > =A0 =A0 =A0 =A0 =A0slot11 DE500-BA Network Con =A0ewa0.0.0.11.0 =A000-00-= F8-08-F4-F3 > > 2. What do most of the people who have one of these things have on them > =A0 =A0 =A0OS wise? =A0Linux, BSD, OpenVMS, DigitalUnix or whatever? > > 3. How do I update to the last BIOS or however you say it in the dec worl= d? > =A0 =A0 =A0I understand there is a V5.8 out. > > 4. What is the biggest scsi drive I can stick in this thing and just have= it > work? > =A0 =A0 =A0How many of them can I string togetther inside the box? > > 5. When looking at stuff and the Internet it is difficulet to tell if wha= t I > am > =A0 =A0 =A0reading is relevant or not, confused on exactly what the box i= s. > > 6. I have been thinking of just setting up a server for "stuff" on my > =A0 =A0 local net but I am also thinking that the electricity to run this= thing > =A0 =A0 might be a little high vs. a cheap low power x86 clone server. > > Hope the above helps you help me. > > thanks, > charles.....- Hide quoted text - > > - Show quoted text - Try these: >>> sho dev >>> sho config >>> show bootdef_dev Let me know what you find. Thanks. ------------------------------ Date: Tue, 19 Aug 2008 14:53:44 -0400 From: JF Mezei Subject: Re: What to do now with a DEC Server 3000? Message-ID: <48ab17af$0$1817$c3e8da3@news.astraweb.com> Re: media kits for the alpha. I might be able to accidentally allow you to peek under the table and FTP a big zip file. (8.3). However, you would need to either burn it to a CD and boot the alpha from the CD, or have some exsiting VMS system that could act as boot server. You will however need licences for VMS and the layered products, and for that you need to be a member of "DECUS" (or whatever its name is this week where you live). ------------------------------ End of INFO-VAX 2008.454 ************************