INFO-VAX Wed, 20 Aug 2008 Volume 2008 : Issue 455 Contents: Cheaper ATI Radeon Cards from Island Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: 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: DS10L power supply mystery Re: DS10L power supply mystery Re: DS10L power supply mystery Re: DS10L power supply mystery Re: invalidating I-cache on I-tanium Re: invalidating I-cache on I-tanium Re: lib$find_file on Pascal Re: lib$find_file on Pascal Re: Updated with list (Re: Old DECservers, DEChubs etc. available to a good home ---------------------------------------------------------------------- Date: Wed, 20 Aug 2008 08:57:08 -0400 From: "David" Subject: Cheaper ATI Radeon Cards from Island Message-ID: We are now providing our own branded ATI Radeon 64MB PCI Cards We also provide the driver installation CD to run with OpenVMS 7.3> Part Number IC-PBXGG-RA Price per unit is $179 Buy online at https://icusc.com -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= ------------------------------ Date: Wed, 20 Aug 2008 02:51:24 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 20, 5:20 am, "Tom Linden" wrote: > 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: 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. > > 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 OpenVMSwww.kednos.com We are quite a bunch at signedness.org that all share the interest of IT security. But I speak for all of us when I say that learning new things and solving a puzzle never gets boring. It does not have to do with breaking security mechanisms though (we get aroused by solving all kind of technical and logical problems). However, since all of us work with computers in one way or another (some does this kind of work for a living, some are system administrators etc.) that is what we have in common and we can combine the interest in solving puzzles with learning new stuff in the area of our profession. I think that most of us got into security related work out of curiosity, we wanted to understand how things *really* worked. ------------------------------ Date: Wed, 20 Aug 2008 12:42:07 +0200 From: "P. Sture" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , "Michael D. Ober" wrote: > "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? I don't think mine would stop a .303 but a .22, possibly. -- Paul Sture ------------------------------ Date: 20 Aug 2008 11:08:50 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In message <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com> bugs@signedness.org writes: >On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: >> >> 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. My PoC for zapping AUTHPRIV is 172 bytes (116 code, 52 data+linkage), you win. >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. Once when our security guy was relating an incident, he said he gets alternately amused and aggravated by how badly the attackers stumble around on unfamiliar systems (this is just among Unix variants). The security group often monitor attacks in progress for some time to gather intelligence on the hackers, but watching them read man pages over and over gets a bit tedious. David L. Jones | Phone: (614) 271-6718 Ohio State University | Internet: 140 W. 19th St. | jonesd@ecr6.ohio-state.edu Columbus, OH 43210 | vman+@osu.edu Disclaimer: I'm looking for marbles all day long. ------------------------------ Date: 20 Aug 2008 07:34:58 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , "Richard B. Gilbert" writes: > 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. >> > > Sorry, I just broke into your house, found a working outlet, plugged in > that computer. . . . I note that you were not successfull in deploying any bullets while doing so. ------------------------------ Date: 20 Aug 2008 07:36:17 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article , "Richard B. Gilbert" writes: > > 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? I suspect there were paths through the BA213 chassis where that would do no harm. ------------------------------ Date: 20 Aug 2008 07:39:33 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: 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? OpenVMS VAX 7.3 is fully supported. 6.2 and 5.5-2 are supported under what DEC used to call "prior version support" (HP makes more distinctions). DEC provided a security MUP for 4.6 and 4.7 after they were no longer supported, just to protect customers still using them and their own reputation. If HP doesn't provide patches for 5.5-2, 6.2, and 7.3, they're not owning up to there promises. Unfortunately VAX owners already know about HP's promises. ------------------------------ Date: Wed, 20 Aug 2008 12:42:55 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E629.3439135C@SendSpamHere.ORG> In article <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com>, bugs@signedness.org writes: >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: >>{...snip...} > >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? Demoed in the post (most of which I've deleted in this reply to save bandwidth), I merely cut and pasted some characters. What I was try- ing to do is show that elevated privies (all of them!) can be easily had without anything more than 20 Alpha machine instructions and the clean return to DCL too. It's a bit scary. The "address" can be represented with ASCII character... well, the first (lower) three bytes. I typed in the 511, UP arrows and then the 3 characrters followed by a delete which is the upped %x7F of the address. Such a thing could be implemented using a method described in one of the prior posts in this thread that I epressed concern about to weap- onize this. I should hope that nobody does that! >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. I don't want to other than to garner a better understanding of how it COULD be. I was more interested in the 20 Alpha instructions bit of code. First time I've used a register stack frame too in VMS. ;) >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. I looked over the presentation's slides which were loaded up to the deathrow cluster web server. You made alot of extra work for your- selves using $CREPRC. You are correct in that what I did in exploiting the fact that INSTALL is installed with CMKRNL would not work with only OPER. What I was in- tent on proving is how little code is needed to grant the realm of priv- ileges to the non-privied process. >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 However, you didn't need the code to pass to the CHMK intruction (PAL code on Alpha) to access $CREPRC. System services are callable by user code to request that the OS perform some requested function on behalf of its invoker. These addresses are well known, can be expressed in 32 bits (though sign extended for the JSR Rret,(Rtarget)), and use the same CHMmode instruction (PALcode) you exploited. >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. Again, not necessary. System services have well defined entry addres- ses. If you can type LINK, you can get these. >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. I'm not so certain that the *vendor* understands it but the good folks in VMS engineering certainly do. :) What you stepped upon was a, IMHO, rather sloppy bit of BLISS code in a run-time library and a routine that is used by many utilities. I'd hope that some effort will now be put into a good code review of some of the other similar code. >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? LD_PRELOAD... look at LIB$FIND_IMAGE_SYMBOL in VMS. There's also the system service for image activation. >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. -- 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: Wed, 20 Aug 2008 12:44:47 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E629.76EC1177@SendSpamHere.ORG> In article , "Tom Linden" writes: >{...snip...} > >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= >.. Me? Academics! -- 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: Wed, 20 Aug 2008 12:49:50 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E62A.2BC56290@SendSpamHere.ORG> In article , JONESD@ecr6.ohio-state.edu (David Jones) writes: >In message <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com> > bugs@signedness.org writes: > >>On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: >>> >>> 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. > >My PoC for zapping AUTHPRIV is 172 bytes (116 code, 52 data+linkage), you >win. :) The idea was to keep it small as the *supported* mechanism I used allows for 252 bytes to be loaded! I happy to see that I'm not the only one entertained with such academic exercises. -- 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: Wed, 20 Aug 2008 08:05:11 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <8b6704ef-f6ec-4a5b-876e-56f074dfb4d0@8g2000hse.googlegroups.com> Hi, Christer here.. > I looked over the presentation's slides which were loaded up to the > deathrow cluster web server. =A0You made alot of extra work for your- > selves using $CREPRC. > > You are correct in that what I did in exploiting the fact that INSTALL > is installed with CMKRNL would not work with only OPER. =A0What I was in- > tent on proving is how little code is needed to grant the realm of priv- > ileges to the non-privied process. > Two different but both valid approaches depending on what you want to achieve. Btw the first exploit we wrote was actually for the finger bug on VAX in which we took a different approach. Since we we SYSPRV on the bug we modified SYSUAF.DAT using a system service to enable all privs on our account (the libc shellcode idea in the presentation was quickly abandoned and should be ignored :)). The overflow bug was a bit different with many targets running under different privs, so we decided to take a different approach and make the shellcode a bit more generic (something that would be useful regardless of obtained privs). Maybe we in retrospect should have taken another route with the alpha shellcode, but there is to our defense some logic behind the decision to do what we did. The idea was to be able to reuse the shellcode and execute a binary on a remote system if a remote vulnerability was found. The fact that we adhered only to a bare minimum of the calling standard to "get the job done" and consequently didn't exactly terminate the exploited process cleanly can be explained by lazyness, having very little time (spending most time trying to figure out even the most basic things like how to set file permissions in VMS :)) and frustration over feeling completely crippled in an environment we were and still are new to. > >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 > > However, you didn't need the code to pass to the CHMK intruction (PAL > code on Alpha) to access $CREPRC. =A0System services are callable by user > code to request that the OS perform some requested function on behalf > of its invoker. =A0These addresses are well known, can be expressed in > 32 bits (though sign extended for the JSR Rret,(Rtarget)), and use the > same CHMmode instruction (PALcode) you exploited. > I'm not completely sure I understand what you are saying here. My interpretation is that you are saying there are library functions we can call that will take care of calling $CREPRC for us. My question then would be (not knowing how runtime linking works on vms) how "static" these address are across VMS releases? On every system I'm familiar with library addresses changes between releases / library versions. While it would work great in local exploits, the approach may not be the best one for remote exploitation. > >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. > > Again, not necessary. =A0System services have well defined entry addres- > ses. =A0If you can type LINK, you can get these. > Actual system services or library stubs that calls them? > >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. > > I'm not so certain that the *vendor* understands it but the good folks > in VMS engineering certainly do. :) > > What you stepped upon was a, IMHO, rather sloppy bit of BLISS code in > a run-time library and a routine that is used by many utilities. =A0I'd > hope that some effort will now be put into a good code review of some > of the other similar code. > > >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? > > LD_PRELOAD... look at LIB$FIND_IMAGE_SYMBOL in VMS. =A0There's also the > system service for image activation. > That function seems more analogous to dlsym() in UNIX than LD_PRELOAD, but that is useful info too. > >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. > > -- > 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.- Hide quoted text - > > - Show quoted text - ------------------------------ Date: Wed, 20 Aug 2008 08:17:58 -0700 (PDT) From: IanMiller Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Watch for SMGRTL patches being released. I've seen the message for VMS831H1I_SMGRTL-V0100 and expect ones for other versions will be following. ------------------------------ Date: Wed, 20 Aug 2008 09:18:42 -0700 (PDT) From: IanMiller Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: SMGRTL patches for various versions have been announced ------------------------------ Date: Wed, 20 Aug 2008 09:28:07 -0700 (PDT) From: IanMiller Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On 20 Aug, 17:21, Jan-Erik S=F6derholm wrote: > IanMiller wrote: > > SMGRTL patches for various versions have been announced > > What does "have been announced" actualy mean ? > Are they available ? And if so, how ? Announced on the OpenVMS.Org Alerts email list. I don't know of any other announcement. I do not see the patches in ftp://ftp.itrc.hp.com/openvms_patches/ as yet. ------------------------------ Date: Wed, 20 Aug 2008 17:33:10 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E651.C048F3DA@SendSpamHere.ORG> In article <8b6704ef-f6ec-4a5b-876e-56f074dfb4d0@8g2000hse.googlegroups.com>, bugs@signedness.org writes: >Hi, Christer here.. > >> I looked over the presentation's slides which were loaded up to the >> deathrow cluster web server. =A0You made alot of extra work for your- >> selves using $CREPRC. >> >> You are correct in that what I did in exploiting the fact that INSTALL >> is installed with CMKRNL would not work with only OPER. =A0What I was in- >> tent on proving is how little code is needed to grant the realm of priv- >> ileges to the non-privied process. >> > >Two different but both valid approaches depending on what you want to >achieve. Btw the first exploit we wrote was actually for the finger >bug on VAX in which we took a different approach. Since we we SYSPRV >on the bug we modified SYSUAF.DAT using a system service to enable all >privs on our account (the libc shellcode idea in the presentation was >quickly abandoned and should be ignored :)). There are some security packages that will thwart modification of the UAF by non-authorized users. That you were able to modify the UAF is academic but your method would very likely set off system alarms from your accessing and modifiaction of the UAF. >The overflow bug was a bit different with many targets running under >different privs, so we decided to take a different approach and make >the shellcode a bit more generic (something that would be useful >regardless of obtained privs). Maybe we in retrospect should have >taken another route with the alpha shellcode, but there is to our >defense some logic behind the decision to do what we did. > >The idea was to be able to reuse the shellcode and execute a binary on >a remote system if a remote vulnerability was found. The fact that we >adhered only to a bare minimum of the calling standard to "get the job >done" and consequently didn't exactly terminate the exploited process >cleanly can be explained by lazyness, having very little time >(spending most time trying to figure out even the most basic things >like how to set file permissions in VMS :)) and frustration over >feeling completely crippled in an environment we were and still are >new to. You're thinking in unixland. Exec() or system() to execute some com- mand to do work. There's a much more robust environment in VMS. >> >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 >> >> However, you didn't need the code to pass to the CHMK intruction (PAL >> code on Alpha) to access $CREPRC. =A0System services are callable by user >> code to request that the OS perform some requested function on behalf >> of its invoker. =A0These addresses are well known, can be expressed in >> 32 bits (though sign extended for the JSR Rret,(Rtarget)), and use the >> same CHMmode instruction (PALcode) you exploited. >> > >I'm not completely sure I understand what you are saying here. My >interpretation is that you are saying there are library functions we >can call that will take care of calling $CREPRC for us. My question >then would be (not knowing how runtime linking works on vms) how >"static" these address are across VMS releases? > >On every system I'm familiar with library addresses changes between >releases / library versions. While it would work great in local >exploits, the approach may not be the best one for remote >exploitation. The can on VMS too but the image activator takes care of it. You used the image activator when you ran your program. -- 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: Wed, 20 Aug 2008 02:12:00 -0600 From: Jeff Campbell Subject: Re: Disk remains in HostUnavailable for a very long time Message-ID: <1219219494_339@isp.n> JF Mezei wrote: > 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 ? $ mcr sysgen SYSGEN> use current SYSGEN> set mystic_vision true SYSGEN> write current SYSGEN> ^Z 8-) 8-) 8-) ----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= - Total Privacy via Encryption =--- ------------------------------ Date: Wed, 20 Aug 2008 02:07:07 -0400 From: "William Webb" Subject: Re: DS10L power supply mystery Message-ID: <8660a3a10808192307v30d4de30vec81c298ab032f47@mail.gmail.com> On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak wrote: > 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 > Pat- The last time I saw field service use a scope was when they were troubleshooting an LP27. : - ) WWWebb ------------------------------ Date: Wed, 20 Aug 2008 04:27:13 -0700 (PDT) From: FrankS Subject: Re: DS10L power supply mystery Message-ID: <9dc070de-9ef4-4a53-a44c-b56ba83fae65@m73g2000hsh.googlegroups.com> On Aug 19, 9:13=A0pm, "William Webb" wrote: > probably cheaper to order an entire DS10L from our favorite vendor in > Savannah/Tybee Island than it would be to find a power supply. I have a DS10L with a bad power supply as well. I came across replacements somewhere online for around $80 (US). I bought the DS10L on eBay for around $150. So, the power supply is actually cheaper though I did choose to buy another DS10L anyway. ------------------------------ Date: Wed, 20 Aug 2008 07:48:41 -0400 From: "Richard B. Gilbert" Subject: Re: DS10L power supply mystery Message-ID: William Webb wrote: > On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak wrote: >> 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 >> > > Pat- > > The last time I saw field service use a scope was when they were > troubleshooting an LP27. > > : - ) > > WWWebb My last time was ca. 1984/85 on a VAX 11/750. My CE at the time was probably among the last who knew what to do with an oscilloscope. From about that time on, Field Service just swapped boards until the system started working again. ------------------------------ Date: Wed, 20 Aug 2008 07:20:31 -0700 (PDT) From: DaveG Subject: Re: DS10L power supply mystery Message-ID: On Aug 20, 6:48=A0am, "Richard B. Gilbert" wrote: > William Webb wrote: > > On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak w= rote: > >> 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 o= n. > >>>> 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 sa= me > >>>> 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 DS10= L, > >>>> wait a second or 3 and put it back in. At that point, the unit power= s > >>>> 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 st= ops > >> drive to a switching transistor. There is likely an IC (or several) th= at has > >> overvoltage, undervoltage, and overcurrent sensing and triggering any = of > >> these will stop it. It may also have a smaller standby type of switchi= ng > >> 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 poi= nt of > >> causing shutdowns and even subtle things like unexplained errors or cr= ashes. > >> 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 h= undred > >> 14-pin DIP ICs during the previous owner's attempt to repair the switc= hing > >> power supply. In the dim time, switchers were new and cantankerous and= few > >> people understood them. It must have taken several seconds for the mac= hine > >> to die that horrible death and the poppencorken mit spitzensparken wou= ld > >> have been enough to clear the room of any lurking veeblefesters. > > >> PJ > > > Pat- > > > The last time I saw field service use a scope was when they were > > troubleshooting an LP27. > > > : - ) > > > WWWebb > > My last time was ca. 1984/85 on a VAX 11/750. =A0My CE at the time was > probably among the last who knew what to do with an oscilloscope. =A0From > about that time on, Field Service just swapped boards until the system > started working again.- Hide quoted text - > > - Show quoted text - We had a scope (Tektronics, not HP:0) here last millenium. I once turned it on and started playing with it - I'd used scopes for years in a former life - and some asked me "what's that?" I guess they'd never seen bad sci-fi movies growing up or heard the TV lines - do not attempt to adjust your vertical or horizontal, we are in control; or words to that affect. Remember? ------------------------------ Date: Wed, 20 Aug 2008 10:44:05 -0400 From: "David" Subject: Re: DS10L power supply mystery Message-ID: <%2Wqk.13354$kh2.810@bignews3.bellsouth.net> As these Power supplies are not customer-repairable why not buy a spare for $49 ? We have hundreds in stock David -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= "JF Mezei" wrote in message news: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: Wed, 20 Aug 2008 07:50:00 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DS10L power supply mystery Message-ID: <6446e741-2f0a-49f5-9bbd-c860506a6714@z72g2000hsb.googlegroups.com> On Aug 20, 3:20 pm, DaveG wrote: > On Aug 20, 6:48 am, "Richard B. Gilbert" > wrote: > > > > > William Webb wrote: > > > On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak wrote: > > >> 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 > > > > Pat- > > > > The last time I saw field service use a scope was when they were > > > troubleshooting an LP27. > > > > : - ) > > > > WWWebb > > > My last time was ca. 1984/85 on a VAX 11/750. My CE at the time was > > probably among the last who knew what to do with an oscilloscope. From > > about that time on, Field Service just swapped boards until the system > > started working again.- Hide quoted text - > > > - Show quoted text - > > We had a scope (Tektronics, not HP:0) here last millenium. I once > turned it on and started playing with it - I'd used scopes for years > in a former life - and some asked me "what's that?" I guess they'd > never seen bad sci-fi movies growing up or heard the TV lines - do not > attempt to adjust your vertical or horizontal, we are in control; or > words to that affect. Remember? No, don't remember that at all. Definitely not. ;) Others apparently do though: http://www.youtube.com/watch?v=vmY8gTG8f5E Last DEC engineer I remember using a scope would probably be doing RM03 head alignment (attached to an 11/70). Or maybe something deep inside a TU16? ps stay behind after class for mis-spelling Tektronix. pps for any flash-impaired and Youtube-incompatible readers here, the series was (in case it's not obvious) The Outer Limits. ------------------------------ Date: Wed, 20 Aug 2008 09:23:18 -0700 (PDT) From: DaveG Subject: Re: DS10L power supply mystery Message-ID: <0e8f0647-fefb-4441-9f8c-d3a3abdbde79@d1g2000hsg.googlegroups.com> On Aug 20, 9:50=A0am, johnwalla...@yahoo.co.uk wrote: > On Aug 20, 3:20 pm, DaveG wrote: > > > > > On Aug 20, 6:48 am, "Richard B. Gilbert" > > wrote: > > > > William Webb wrote: > > > > On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak wrote: > > > >> 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 th= e 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 p= owers > > > >>>> back on, I can hear the 2 disks spinning up, air flow in the bac= k is > > > >>>> greater and getting warmer quickly, and the opower up sequence i= s > > > >>>> displayed on the console, machine boots normally. > > > > >>>> Can anyone explain this ? > > > > >>>> What would be the difference between unplugging the unit and usi= ng a > > > >>>> large breaker to feed power back to it ? > > > > >>> Hi, jf > > > > >>> probably cheaper to order an entire DS10L from our favorite vendo= r 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 probabl= y 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 swi= tching > > > >> supply internally, to keep the switching controller live, even if = the main > > > >> switcher (power factor controller) or one of the subordinate switc= hers 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 eac= h DC line > > > >> from the switcher. They should have no more than about 50mV peak n= oise. 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 o= r crashes. > > > >> An ESR (equivalent series resistance) meter can be used to check t= he > > > >> 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 mos= t of the > > > >> foil off all of the circuit boards and many chunks out of the coup= le hundred > > > >> 14-pin DIP ICs during the previous owner's attempt to repair the s= witching > > > >> 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 > > > > > Pat- > > > > > The last time I saw field service use a scope was when they were > > > > troubleshooting an LP27. > > > > > : - ) > > > > > WWWebb > > > > My last time was ca. 1984/85 on a VAX 11/750. =A0My CE at the time wa= s > > > probably among the last who knew what to do with an oscilloscope. =A0= From > > > about that time on, Field Service just swapped boards until the syste= m > > > started working again.- Hide quoted text - > > > > - Show quoted text - > > > We had a scope (Tektronics, not HP:0) here last millenium. =A0I once > > turned it on and started playing with it - I'd used scopes for years > > in a former life - and some asked me "what's that?" =A0I guess they'd > > never seen bad sci-fi movies growing up or heard the TV lines - do not > > attempt to adjust your vertical or horizontal, we are in control; or > > words to that affect. =A0Remember? > > No, don't remember that at all. Definitely not. ;) > > Others apparently do though:http://www.youtube.com/watch?v=3DvmY8gTG8f5E > > Last DEC engineer I remember using a scope would probably be doing > RM03 head alignment (attached to an 11/70). Or maybe something deep > inside a TU16? > > ps > stay behind after class for mis-spelling Tektronix. > pps > for any flash-impaired and Youtube-incompatible readers here, the > series was (in case it's not obvious) The Outer Limits. I indeed mis-spelled Tektronix. My bad and I'll write that many times on a black board when I find one. ;-) ------------------------------ Date: Wed, 20 Aug 2008 18:23:27 +0200 From: "P. Sture" Subject: Re: DS10L power supply mystery Message-ID: In article <6446e741-2f0a-49f5-9bbd-c860506a6714@z72g2000hsb.googlegroups.com>, johnwallace4@yahoo.co.uk wrote: > On Aug 20, 3:20 pm, DaveG wrote: > > On Aug 20, 6:48 am, "Richard B. Gilbert" > > wrote: > > > > > > > > > William Webb wrote: > > > > On Tue, Aug 19, 2008 at 11:49 PM, patrick jankowiak > > > > wrote: > > > >> 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 > > > > > > Pat- > > > > > > The last time I saw field service use a scope was when they were > > > > troubleshooting an LP27. > > > > > > : - ) > > > > > > WWWebb > > > > > My last time was ca. 1984/85 on a VAX 11/750. My CE at the time was > > > probably among the last who knew what to do with an oscilloscope. From > > > about that time on, Field Service just swapped boards until the system > > > started working again.- Hide quoted text - > > > > > - Show quoted text - > > > > We had a scope (Tektronics, not HP:0) here last millenium. I once > > turned it on and started playing with it - I'd used scopes for years > > in a former life - and some asked me "what's that?" I guess they'd > > never seen bad sci-fi movies growing up or heard the TV lines - do not > > attempt to adjust your vertical or horizontal, we are in control; or > > words to that affect. Remember? > > No, don't remember that at all. Definitely not. ;) > > Others apparently do though: http://www.youtube.com/watch?v=vmY8gTG8f5E Do you remember "Do Not Adjust Your Set"? (A UK kids programme, also to be found on Youtube, and notable for Bonzo Dog Band and early appearances of Eric Idle, Terry Jones etc.). > Last DEC engineer I remember using a scope would probably be doing > RM03 head alignment (attached to an 11/70). Or maybe something deep > inside a TU16? Ditto, except with RM05s and an 11/750. -- Paul Sture ------------------------------ Date: Wed, 20 Aug 2008 10:07:29 -0400 From: "John Reagan" Subject: Re: invalidating I-cache on I-tanium Message-ID: On I64, there is an EVAX_IMB macro inside of STARLET.MLB that will do the right thing. You can just say EVAX_IMB on both Alpha and I64 and the correct code will come out. As for the INSTRUCTION_MB macro, I found some confusing comments, but I think that it is Alpha only. It seems like IA64 work was started on the macro, but it was never finished. Looking at one use, I see it conditionalized for Alpha only. The else path for I64 has an explicit CALLS to a routine named MMG$INSTRUCTION_MB. Why couldn't INSTRUCTION_MB be changed to just call MMG$INSTRUCTION_MB? Beats me. I didn't write it. John "Jur van der Burg" <"lddriver at digiater dot nl"> wrote in message news: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: Wed, 20 Aug 2008 17:42:58 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: invalidating I-cache on I-tanium Message-ID: <00A7E653.1EB6C485@SendSpamHere.ORG> In article , "John Reagan" writes: >On I64, there is an EVAX_IMB macro inside of STARLET.MLB that will do the >right thing. You can just say > >EVAX_IMB > >on both Alpha and I64 and the correct code will come out. Thanks John, save that EVAX_IMB takes arguments on IA64. I have EVAX_IMB in a great deal of Alpha code. I now will need to specify an address and the length of the code address region to invalidate with the EVAX_IMB. >As for the INSTRUCTION_MB macro, I found some confusing comments, but I >think that it is Alpha only. It seems like IA64 work was started on the >macro, but it was never finished. Looking at one use, I see it >conditionalized for Alpha only. The else path for I64 has an explicit CALLS >to a routine named MMG$INSTRUCTION_MB. Why couldn't INSTRUCTION_MB be >changed to just call MMG$INSTRUCTION_MB? Beats me. I didn't write it. OK. Looks like somebody thought about INSTRUCTION_MB but never went back to it. -- 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: Wed, 20 Aug 2008 00:20:36 -0700 (PDT) From: Ramon Jimenez Subject: Re: lib$find_file on Pascal Message-ID: <07587c48-5094-4119-94ba-c69153855312@m3g2000hsc.googlegroups.com> Thank you Hein. I mispelled the input it called Xoutfile, yes the resultant file is called dummy, that's how I found I changed it to another value with the same result. The way the program is calling the function is: lib$find_file ( Xoutfile, dummy, context, 'DATAFILE.' ) = RMS $_NORMAL; lib$find_file_end ( context := context ) Data definitions are, (I've to use the same definition but I got compilation error) Xoutfile : VARYING[ 132 ] OF CHAR := ZERO; dummy : PACKED ARRAY[ 1..200 ] OF CHAR; I dont found any other place inside the code were "dummy" it's used. Regards Ramon ------------------------------ Date: Wed, 20 Aug 2008 10:08:46 -0400 From: "John Reagan" Subject: Re: lib$find_file on Pascal Message-ID: <7sKdnZt3Gsv4uDHVnZ2dnUVZ_tvinZ2d@earthlink.com> I'll answer it there. John "Hein RMS van den Heuvel" wrote in message news:8bcb150f-737f-4b99-b95e-2bee93bf252e@59g2000hsb.googlegroups.com... On Aug 19, 10:21 am, Ramon Jimenez wrote: > We are porting a Pascal app from a 32 bit VAX to a new Integrity fyi... This topic is cross-posted in the itrc OpenVMS forum: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1260793 Hein. ------------------------------ Date: Wed, 20 Aug 2008 07:48:29 -0700 (PDT) From: vaxdecman@aol.com Subject: Re: Updated with list (Re: Old DECservers, DEChubs etc. available to a good home Message-ID: Dave, How much to ship the following to US zip code 48170? Thanks. Greg On Aug 19, 7:52=A0am, David B Sneddon wrote: > And here is the initial list: > > =A0 1 x DECserver 700-16 > =A013 x BA356 SBB P/S (blue) > =A0 4 x VAXstation 4000 P/S > > =A0 2 x HSZ50 > =A0 2 x DWZZH-05 (in BA356) > > Dave ------------------------------ End of INFO-VAX 2008.455 ************************