INFO-VAX Sat, 16 Aug 2008 Volume 2008 : Issue 446 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: 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: DSPP & OpenVMS Re: DSPP & OpenVMS Re: DSPP & OpenVMS Re: DSPP & OpenVMS Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) Re: Help needed with / confused by AST routine (VAX,COBOL) Re: NFS - OpenVMS to OpenVMS Re: NFS - OpenVMS to OpenVMS Re: OT: noVMS Alphas... ---------------------------------------------------------------------- Date: Fri, 15 Aug 2008 11:00:49 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com> On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote: > In article , samp...@gmail.com writes: > > > > >On Aug 15, 3:35=A0pm, "R.A.Omond" wrote: > >> samp...@gmail.com wrote: > >> Y'know ... I may be a newbie in this VMS thingy (a mere 26.5 years...) > >> but I actually didn't understand what that is meant to mean. > > >> I'm a skeptic and proud of it, but I'm beginning to suspect that > >> this is all a hoax. > > >Ok, I'll have a go at making that more understandable: > > >1. The input (=3Dshellcode) after the overflow will be executed by the > >process with elevated privileges > >2. There are quite a few input restrictions in what can be fed in > >through the CLI, making any meaningful attack difficult through just > >placing some shellcode after the overflow. > >3. It is possible to execute shellcode stored in logicals, however. > >4. Therefore the code injected after the overflow executes some other > >code stored in a logical. > > I've mucked around quite a bit in DCL and I don't see how you get some > command or command procedure (shellcode) stored in a logical to be ex- > ecuted by DCL when you ACCVIO an image. > > -- > 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. You really don't get it. At all. It has nothing to do with running code in a logical when a program _causes_ an access violation since the exploit take advantage of an error to take control of the execution flow. Since the PC is controlled in the CLI bug we simply jump to the address of a logical that contains the shellcode that we want to run. In the case of the CLI bug (THE BUG IS NOT IN THE DCL SHELL) we use a shellcode to execute the create process system service which in turn executes FILE.EXE. However, we did not bother to add a clean exit after the create process shellcode so the process crashes when FILE.EXE has been executed. This is not a problem since FILE.EXE already have been executed with the privileges of the target program inherited. Please pick up some book on exploit development and think a little before doing statements about things that you obviously don't know anything about. ------------------------------ Date: Fri, 15 Aug 2008 11:02:00 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <7fd8b8da-c5c1-4160-b8c1-916926f9f92d@m73g2000hsh.googlegroups.com> On Aug 15, 7:42 pm, Jan-Erik S=F6derholm wrote: > johnwalla...@yahoo.co.uk wrote: > > On Aug 15, 3:35 pm, "R.A.Omond" wrote: > > If all this is done correctly you don't see an ACCVIO, you just end up > > with unintended code being silently executed, potentially in the > > context of an exploitable program. I haven't watched the videos but > > the ACCVIOs here aren't what I'd expect to see as part of a successful > > exploit; > > IOW, isn't the ACCVIO a *proof* that the exploit was > *un*-successful ? They tried, but VMS "got them"... > > Jan-Erik. Yeah right .... You should probably get a book about exploit development as well. ------------------------------ Date: 15 Aug 2008 13:14:45 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <2970caa7-7806-4278-996e-79af773dc750@r66g2000hsg.googlegroups.com>, bugs@signedness.org writes: > On Aug 15, 5:56 pm, VAXman- @SendSpamHere.ORG wrote: >> >> I've mucked around quite a bit in DCL and I don't see how you get some >> command or command procedure (shellcode) stored in a logical to be ex- >> ecuted by DCL when you ACCVIO an image. >> > > You really don't get it. At all. I think that Brian may be thinking that shellcode is a series of DCL commands instead of machine code. I think it's already been pointed out on this thread already what the definition of shellcode is in the context that you are using it, but Wikipedia has a writeup in case Brian missed the earlier message: http://en.wikipedia.org/wiki/Shellcode Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Fri, 15 Aug 2008 12:57:51 -0700 (PDT) From: sampsal@gmail.com Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 8:49=A0pm, JF Mezei wrote: > samp...@gmail.com wrote: > > 3. It is possible to execute shellcode stored in logicals, however. > > 4. Therefore the code injected after the overflow executes some other > > code stored in a logical. > > Since there is no such thing as "shellcode" in VMS, it would greatly > help if you use terminology native to VMS so we could understand it. > > For an application to execute the content of a logical name, it would > need to first extract those contents into memory, and then declare that > area of memory to be executable and then branch to it. This doesn't > happen by mistake/luck. Ok, sorry guys, I'll stop using the term shellcode and use the term exploit payload from now on, if that's ok with everyone? Bugs? Anyway, I'm not going to rehash the whole explanation, but yes JF, you're right, it doesn't happen by mistake or luck, instead there's a small payload that follows the overflow which triggers the system into executing the larger payload stored in the logical. I hope this makes a bit more sense. Bugs, can you verify my explanation is correct? Sampsa ------------------------------ Date: Fri, 15 Aug 2008 13:32:34 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <960b37a6-1408-4a9d-9cb7-75ea57cd10f1@d45g2000hsc.googlegroups.com> On Aug 15, 9:03 pm, JF Mezei wrote: > b...@signedness.org wrote: > > since the exploit take advantage of an error to take control of the > > execution flow. > > You mean you have discovered error handlers in VMS where you can > register a subroutine to execute when errors/access violations happen in > an executable program ? > > Those are fully documented. No exploit there. > > > Since the PC is controlled in the CLI bug we simply jump to the > > address of a logical that contains the > > shellcode that we want to run. > > How do you obtain the address of that logical ? This is pretty critical > to knowing if you can jump to it or not. > > > However, we did not bother > > to add a clean exit after the create process shellcode so the process > > crashes when FILE.EXE > > has been executed. > > You mean you don't know about the "exit(1);" statement in C ? > > > Please pick up some book on exploit development and think a little > > before doing statements > > about things that you obviously don't know anything about. > > For someone to find such an exploit, one would need a fair amount of VMS > experience. And since you use terminology that is completely foreign to > VMS, it is hard to understand how you could have enough experience with > VMS to find such an exploit. > > For instance, if Mr VAXman had found this exploit, he would have given > an explanation using terminology that is native to VMS because we know > he has a lot of experience with VMS. I have been around long enough to realise that whatever bit of IT you work in, it has its own private terminology (as do many trades and professions). When I started my 2nd job, a couple of decades ago, I heard a lot of references to "scenario interpreters". Because I wasn't directly involved, it took me weeks to work out that what was actually being talked about was a test script interpreting tool with a fancy name. Same thing here. A common set of terminology is helpful, but often doesn't exist across different communities. How you get that common terminology/language is interesting, but I thought it was mostly the stereotypical English (and Yanks) that insisted that everyone changed to speak in *their* language... Wrt obtaining the address of the logical/shellcode etc: there are lots of ways, depending on the circumstances. In the Windows and Unix world, many exploits have traditionally depended on the fact that the same OS or common application code and data is always loaded at the same virtual address, across different systems and at different times (consequently this staticness has begun to change recently). Does VMS have that predictability too? Even if it doesn't, given that you know what the shellcode looks like and if you have access to the relevant memory, maybe you just go looking for it and adjust (something) accordingly. Maybe. One thing that anyone who's ever done "customer support" work (which is a lot of contributors here, I think) should understand is the well- known concept of "a simple reproducer", with minimal obfuscation and clutter. Language difficulties apart, have we got one of those here yet? ------------------------------ Date: Fri, 15 Aug 2008 13:57:38 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <5f23f662-be91-463d-aafb-a1b030767ecb@w7g2000hsa.googlegroups.com> On Aug 15, 9:49 pm, JF Mezei wrote: > samp...@gmail.com wrote: > > 3. It is possible to execute shellcode stored in logicals, however. > > 4. Therefore the code injected after the overflow executes some other > > code stored in a logical. > > Since there is no such thing as "shellcode" in VMS, it would greatly > help if you use terminology native to VMS so we could understand it. > > For an application to execute the content of a logical name, it would > need to first extract those contents into memory, and then declare that > area of memory to be executable and then branch to it. This doesn't > happen by mistake/luck. There sure is shellcode for OpenVMS, we wrote it. :) And there is no need to extract the contents of a logical into memory, since it is already part of the memory in a process. You can check out wikipedia for information about the shellcode that we refer to: http://en.wikipedia.org/wiki/Shellcode And here is an entry about exploits as well: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 And one on format string vulnerabilities: http://en.wikipedia.org/wiki/Format_string_attack Oh, and just for the record, you don't find an exploit, you find a vulnerability and write an exploit for it. :) As stated earlier, we will not release the exploit to the public yet. We have informed HP about the problems (we did this about two months ago together with information about how to reproduce the bugs) so there will hopefully be a patch for it in a near future. And no, FILE.EXE does not require any privileges, it is just a simple tool to write the current privileges of the process to a file. Please don't tell us to "fuck off", it makes some of us belive that it is a good idea to post sensitive information to fd. And there still is enough information in the previous posts to reproduce the bugs on a vulnerable machine. ------------------------------ Date: Fri, 15 Aug 2008 14:04:31 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 10:03 pm, JF Mezei wrote: > b...@signedness.org wrote: > > since the exploit take advantage of an error to take control of the > > execution flow. > > You mean you have discovered error handlers in VMS where you can > register a subroutine to execute when errors/access violations happen in > an executable program ? > > Those are fully documented. No exploit there. > > > Since the PC is controlled in the CLI bug we simply jump to the > > address of a logical that contains the > > shellcode that we want to run. > > How do you obtain the address of that logical ? This is pretty critical > to knowing if you can jump to it or not. > > > However, we did not bother > > to add a clean exit after the create process shellcode so the process > > crashes when FILE.EXE > > has been executed. > > You mean you don't know about the "exit(1);" statement in C ? We know about the exit() statement, but it is a little more to it to write it in assembly for OpenVMS so we did not spend any time to look up the system service index for it since the exploit works without a clean exit. > > > Please pick up some book on exploit development and think a little > > before doing statements > > about things that you obviously don't know anything about. > > For someone to find such an exploit, one would need a fair amount of VMS > experience. And since you use terminology that is completely foreign to > VMS, it is hard to understand how you could have enough experience with > VMS to find such an exploit. > > For instance, if Mr VAXman had found this exploit, he would have given > an explanation using terminology that is native to VMS because we know > he has a lot of experience with VMS. Well, knowing a whole lot about VMS is not the same thing as writing an exploit. We are pretty sure that VAXman knows a lot more about OpenVMS then we do. We just wrote some exploits for vulnerabilities that we found. This is how we trigger the CLI bug: 1) Start a program using the command line interface library, like install 2) At the prompt (INSTALL>), paste 511 characters and then press the upp arrow key three times to move the history line pointer in memory 3) The pointer now points to a address that will be jumped to, so go ahead and manually write the return address, like pressing the 'b' character 4 times 4) Wait 5) If the machine is vulnerable you will get an access violation. ------------------------------ Date: Fri, 15 Aug 2008 14:19:51 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <850bdecd-1a8b-40a2-9053-d259148afc43@d1g2000hsg.googlegroups.com> On Aug 15, 10:03 pm, JF Mezei wrote: > How do you obtain the address of that logical ? This is pretty critical > to knowing if you can jump to it or not. Yes, that is correct and a lot of time was consumed to determine that the value of a logical actually can be executed. We also looked at other areas without success (CLI Data for example). To find the address of a logical you can write a small program that set a logical and then crashes and scan the core dump as a local user, the logical will be located att the same address when you attack your target. The LOADCODE.EXE tool in the movie loads the shellcode into a logical at a known address before exploiting the target program. You can also use analyze/system and clue process/logical to find the exact address of a logical, but that requires SYSTEM privileges. ------------------------------ Date: Fri, 15 Aug 2008 14:37:42 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 9:57 pm, samp...@gmail.com wrote: > On Aug 15, 8:49 pm, JF Mezei wrote: > > > samp...@gmail.com wrote: > > > 3. It is possible to execute shellcode stored in logicals, however. > > > 4. Therefore the code injected after the overflow executes some other > > > code stored in a logical. > > > Since there is no such thing as "shellcode" in VMS, it would greatly > > help if you use terminology native to VMS so we could understand it. > > > For an application to execute the content of a logical name, it would > > need to first extract those contents into memory, and then declare that > > area of memory to be executable and then branch to it. This doesn't > > happen by mistake/luck. > > Ok, sorry guys, I'll stop using the term shellcode and use the term > exploit payload from now on, if that's ok with everyone? Bugs? > > Anyway, I'm not going to rehash the whole explanation, but yes JF, > you're right, it doesn't happen by mistake or luck, instead there's a > small payload that follows the overflow which triggers the system into > executing the larger payload stored in the logical. I hope this makes > a bit more sense. > > Bugs, can you verify my explanation is correct? > > Sampsa Yup, pretty much like that except that we actually does not need the first stage since we fully control the PC from start and just have to jump to the address of the logical containing the shellcode. Thanx for helping out explaining. ------------------------------ Date: Fri, 15 Aug 2008 18:13:29 -0400 From: bradhamilton Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <48A5FF89.4060903@comcast.net> bugs@signedness.org wrote: [...] > As stated earlier, we will not release the exploit to the public yet. > We have informed HP about the problems (we did this about two months > ago > together with information about how to reproduce the bugs) > so there will hopefully be a patch for it in a near future. Hopefully, you contacted the "right" people at HP - did you get any kind of acknowledgment or response? If not, you probably didn't contact the right people. No fault of yours, and we wouldn't think any less of you. If you contacted them two months ago, and no patches have appeared since then, you probably contacted the wrong people. The only reason I ask this question is that it is sometimes difficult to get the attention of the proper people in HP; if you get the "wrong" folks, the result is the same as singing into a black hole. :-) [...] > Please don't tell us to "fuck off", it makes some of us belive that it > is > a good idea to post sensitive information to fd. I hope you don't think there is a lot of hostility "here"; it's just that some of us are used to information that is presented in a format familiar to us. From initial "reports" of the talk, I (erroneously) assumed that the talk was about simple DCL bugs. All that aside, it seems as though the target must be vulnerable to begin with; I assume that one vector of "infection" is via the FINGER server. What happens when your target does not run the server? Are there other, as yet unknown vectors of "infection" to deliver these payloads? Are you deliberately setting up your target machine (I assume under your physical control) to run wide-open, with all known TCP/IP services enabled (FTP, TELNET, SSH, INETD, etc.)? You would need to know that practically none of "us" would ever run a VMS machine in such a fashion. I know that someone, somewhere is probably running a VMS box like that; if so, they deserve all the exploits they get. :-) Am I close to being on target here? I can take it if I'm way off; just tell me in a polite way. :-) We're all willing to learn here, if there are problems. We await more information. > And there still is enough information in the previous posts to > reproduce the bugs on a vulnerable machine. ------------------------------ Date: Fri, 15 Aug 2008 18:54:32 -0400 From: bradhamilton Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <48A60928.20008@comcast.net> > with all known TCP/IP services enabled (FTP, TELNET, SSH, INETD, etc.)? Oops - fat-finger - I meant IDENTD. :-) ------------------------------ Date: Fri, 15 Aug 2008 16:01:45 -0700 (PDT) From: Rich Jordan Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <2dd58a08-27be-42d2-815c-893e699ee739@m73g2000hsh.googlegroups.com> On Aug 15, 4:04=A0pm, b...@signedness.org wrote: > On Aug 15, 10:03 pm, JF Mezei wrote: > > > b...@signedness.org wrote: > > > since the exploit take advantage of an error to take control of the > > > execution flow. > > > You mean you have discovered error handlers in VMS where you can > > register a subroutine to execute when errors/access violations happen i= n > > an executable program ? > > > Those are fully documented. No exploit there. > > > > Since the PC is controlled in the CLI bug we simply jump to the > > > address of a logical that contains the > > > shellcode that we want to run. > > > How do you obtain the address of that logical ? This is pretty critical > > to knowing if you can jump to it or not. > > > > However, we did not bother > > > to add a clean exit after the create process shellcode so the process > > > crashes when FILE.EXE > > > has been executed. > > > You mean you don't know about the "exit(1);" statement in C ? > > We know about the exit() statement, but it is a little more to it > to write it in assembly for OpenVMS so we did not spend any time > to look up the system service index for it since the exploit works > without > a clean exit. > > > > > > Please pick up some book on exploit development and think a little > > > before doing statements > > > about things that you obviously don't know anything about. > > > For someone to find such an exploit, one would need a fair amount of VM= S > > experience. And since you use terminology that is completely foreign to > > VMS, it is hard to understand how you could have enough experience with > > VMS to find such an exploit. > > > For instance, if Mr VAXman had found this exploit, he would have given > > an explanation using terminology that is native to VMS because we know > > he has a lot of experience with VMS. > > Well, knowing a whole lot about VMS is not the same thing as writing > an exploit. > We are pretty sure that VAXman knows a lot more about OpenVMS then we > do. > We just wrote some exploits for vulnerabilities that we found. > > This is how we trigger the CLI bug: > > 1) Start a program using the command line interface library, like > install > 2) At the prompt (INSTALL>), paste 511 characters and then press the > =A0 =A0 upp arrow key three times to move the history line pointer in > memory > 3) The pointer now points to a address that will be jumped to, so go > ahead > =A0 =A0 and manually write the return address, like pressing the 'b' > character 4 times > 4) Wait > 5) If the machine is vulnerable you will get an access violation. Can't duplicate this on any system, any version of VMS, with or without patches. I then tried from the V8.3 CD boot environment (about as basic as it gets)on a DS10L 466MHz. All tests were with INSTALL. I even installed a fresh V8.3 off the CD on the DS10L and tried, then installed TCPIP, rebooted, tried again, installed DECnet, rebooted, tried again. Tried variants entering a carriage return after the 511 before the up arrows, after the 'bbbb', etc, all I ever get is the expected CLI-W-IVVERB, unrecognized command verb. Entering the 511 characters, then three up arrows, then bbbb then waiting did nothing at all no matter which system or OS version I was running. How long is the wait time? I gave it 4-5 minutes each time. No I haven't watched the videos; can't load foreign codecs on the work peecees. VMS Versions tried: V7.3 with current ECOs, V7.3-2 with current ECOs, V8.2 with current ECOs, V8.3 with current ECOs, V8.2 CD boot environment, V8.3 CD boot environment, V8.3 basic install, V8.3 basic install plus TCPIP, V8.3 basic install plus TCPIP plus DECnet Phase IV. ------------------------------ Date: 16 Aug 2008 00:04:12 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In message <850bdecd-1a8b-40a2-9053-d259148afc43@d1g2000hsg.googlegroups.com>, bugs@signedness.org writes: >To find the address of a logical you can write a small program that >set a logical and then crashes and scan the core dump as a local user, >the logical will be located att the same address when you attack your target. I don't know how this 'core dump as a local user' technique would find what you are looking for, but process logical names are kept in non-shared memory readable in user mode. Therefore, after you call LIB$SET_LOGICAL, you can retrieve the pointer at CTL$GL_LNMHASH and search live memory for the logical name and address of its equivalence string. 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: Sat, 16 Aug 2008 00:37:59 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E29F.4525871C@SendSpamHere.ORG> In article , JONESD@ecr6.ohio-state.edu (David Jones) writes: >In message <850bdecd-1a8b-40a2-9053-d259148afc43@d1g2000hsg.googlegroups.com>, > bugs@signedness.org writes: >>To find the address of a logical you can write a small program that >>set a logical and then crashes and scan the core dump as a local user, >>the logical will be located att the same address when you attack your target. > >I don't know how this 'core dump as a local user' technique would find what >you are looking for, but process logical names are kept in non-shared memory >readable in user mode. Therefore, after you call LIB$SET_LOGICAL, you can >retrieve the pointer at CTL$GL_LNMHASH and search live memory for the logical >name and address of its equivalence string. I fail to see why this code, if it can be executed, must be stored in a logical name block's translation region which may be somewhat arduous to locate and its address is, more likely than not, empirically derived and hard-coded in this exploit. -- 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: Fri, 15 Aug 2008 17:54:01 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 12, 9:58=A0am, samp...@gmail.com wrote: > 2. A CLI buffer overflow on Alphas. Basically any input over 511 > characters causes an overflow, it seems to be possible to have a > privileged process execute arbitrary code. As an interested observer, I was able to duplicate this problem on my DS10L running OpenVMS v7.3-2. I am a little behind in patches on this machine. I tried the same thing on a system which is up-to-date and could not duplicate the problem. It certainly does open an interesting hole that could be exploited. 1) Enter an application which presents a prompt for a command string (for example, MAIL). Presumably any application released with the o/s uses the CLI utility routines to parse the command string. This is then a problem with the CLI routines. 2) Paste 511 characters, then press the up-arrow key three times, then type in some other string of characters. 3) Wait patiently. The application will crash with an access violation. 4) Look at the address where the accvio occurred, and compare it to the hex representation of the characters typed after the three up- arrow keystrokes. ------------------------------ Date: Sat, 16 Aug 2008 01:10:49 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E2A3.DB5ADB63@SendSpamHere.ORG> In article , FrankS writes: >On Aug 12, 9:58=A0am, samp...@gmail.com wrote: >> 2. A CLI buffer overflow on Alphas. Basically any input over 511 >> characters causes an overflow, it seems to be possible to have a >> privileged process execute arbitrary code. > >As an interested observer, I was able to duplicate this problem on my >DS10L running OpenVMS v7.3-2. I am a little behind in patches on this >machine. I tried the same thing on a system which is up-to-date and >could not duplicate the problem. > >It certainly does open an interesting hole that could be exploited. > >1) Enter an application which presents a prompt for a command string >(for example, MAIL). Presumably any application released with the o/s >uses the CLI utility routines to parse the command string. This is >then a problem with the CLI routines. > >2) Paste 511 characters, then press the up-arrow key three times, then >type in some other string of characters. OK. I booted from my virgin V7.3-2 test disk. I entered MAIL. I typed 64 Xs in an edit session and cut from it. Pasted it in 7 times and then deleted one X in the string in the edit session to pasted the last 63 Xs. (That's 511 on my calculator!) I then hit 3 up arrows and typed in XYZZY. >3) Wait patiently. The application will crash with an access >violation. How patiently should I wait? I'm going to bed now. If I'm still at the MAIL prompt in the morning, this is a red herring. -- 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: Fri, 15 Aug 2008 19:22:15 -0700 (PDT) From: FrankS Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 15, 9:10=A0pm, VAXman- @SendSpamHere.ORG wrote: > How patiently should I wait? =A0I'm going to bed now. =A0If I'm still at = the > MAIL prompt in the morning, this is a red herring. E pur si muove. I didn't say my v7.3-2 install was virginal. Just that it wasn't up- to-date. I have no interest in getting your system to crash. I can only honestly tell you that mine does, in the manner described. Furthermore, I have no connection to any of the people that posted the description of the problem in the first place. Just figured I'd try and duplicate it on my own. If you want to study this more on your own then here's the PCSI install history from my system: ----------------------------------- ----------- ----------- -------------------- DEC AXPVMS COBOL V2.9-1453 Full LP Install 15- JUN-2008 11:49:06 DEC AXPVMS COBOL V2.8-1286 Full LP Remove 15- JUN-2008 11:49:06 CPQ AXPVMS OMSVA V1.2 Full LP Install 16- JAN-2008 19:37:10 DEC AXPVMS COBRTL V2.8-670B Full LP Install 16- JAN-2008 17:51:47 DEC AXPVMS COBOL V2.8-1286 Full LP Install 16- JAN-2008 17:49:46 DEC AXPVMS VMS732_AUDSRV V5.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_CLIUTL V1.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_DCL V9.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_FIBRE_SCSI V13.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_LIBRTL V2.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_LOADSS V3.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_MANAGE V6.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_MOUNT96 V3.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_PTHREAD V6.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_SHADOWING V6.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS VMS732_STARLETOLB V1.0 Patch Install 16- JAN-2008 17:35:38 DEC AXPVMS TCPIP V5.4-15ECO7 Full LP Install 16- JAN-2008 16:58:22 DEC AXPVMS TCPIP V5.4-15 Full LP Remove 16- JAN-2008 16:58:22 DEC AXPVMS DWMOTIF_ECO03 V1.3-1 Patch Install 16- JAN-2008 16:57:15 DEC AXPVMS DNVOSIECO03 V7.3-2 Patch Install 16- JAN-2008 16:56:52 DEC AXPVMS DNVOSIMUP01 V7.3-2 Patch Install 16- JAN-2008 16:56:35 DEC AXPVMS VMS732_SYS V14.0 Patch Install 16- JAN-2008 16:52:15 DEC AXPVMS VMS732_UPDATE V13.0 Patch Install 16- JAN-2008 16:37:16 DEC AXPVMS VMS732_PCSI V3.0 Patch Install 16- JAN-2008 16:31:06 CPQ AXPVMS CDSA V2.0-109 Full LP Install 16- JAN-2008 10:30:21 DEC AXPVMS DECNET_OSI V7.3-2 Full LP Install 16- JAN-2008 10:30:21 DEC AXPVMS DWMOTIF V1.3-1 Full LP Install 16- JAN-2008 10:30:21 DEC AXPVMS OPENVMS V7.3-2 Platform Install 16- JAN-2008 10:30:21 DEC AXPVMS TCPIP V5.4-15 Full LP Install 16- JAN-2008 10:30:21 DEC AXPVMS VMS V7.3-2 Oper System Install 16- JAN-2008 10:30:21 HP AXPVMS KERBEROS V2.0-6 Full LP Install 16- JAN-2008 10:30:21 ----------------------------------- ----------- ----------- -------------------- ------------------------------ Date: Fri, 15 Aug 2008 23:00:28 -0400 From: JF Mezei Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <48a6436d$0$18530$c3e8da3@news.astraweb.com> FrankS wrote: > I have no interest in getting your system to crash. Does the 511 character recall buffer thing crash the system, the process or just the application that was running at the time ? Obviously, if you manage to $CMKRNL and call a nasty routine, you can easily crash the system (trying to divide by 0 for instance). But just entering random characters after the 511 up-up-up sequence should just branch you to some random memory address within your process's memory space. Ahhh, I see the vulnerability now... If MAIL or INSTALL is installed with privileges, then getting them to execute some of your own code that exists in your process' memory space would allow that code to execute with whatever privileges that image was installed with (assuming the image did not de-activate the priv at the time you caused it to branch to your own code. ------------------------------ Date: Fri, 15 Aug 2008 20:26:54 -0700 (PDT) From: Hein RMS van den Heuvel Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <7f1b0e7d-6901-4426-b337-8498c14cfe06@m73g2000hsh.googlegroups.com> On Aug 15, 8:37=A0pm, VAXman- @SendSpamHere.ORG wrote: > In article , JON...@ecr6.oh= io-state.edu (David Jones) writes: > > >In message <850bdecd-1a8b-40a2-9053-d259148af...@d1g2000hsg.googlegroups= .com>, > > =A0b...@signedness.org writes: > >>To find the address of a logical you can write a small program that : > I fail to see why this code, if it can be executed, must be stored in a > logical name block's translation region which may be somewhat arduous to > locate Best I understand this, the hack needs any address which can be expressed with a series of ASCII expressable address mappings and survives image activation. Logical names are stored in Process Allocation Region (P1 Pool) which typically starts at (sysgen param dependend) 7Fxxxxxx. So you would use a '~' for a first char. When I tried one, it started at "7FF565A0". That F5 would be hard to express. So you would need many more logicals to eat up space. An other good zone could be the the Process I/O Segment (PIO). A first test showed a buffer at 07B0B4400 ($open x login.com $read x y... $ANAL/SYS... SHOW PROC/RMS=3D(BDBSUM,PIO). If you open a relative fiel with bucket size of 60 or so, then you can make the system read 30KB of 'stuff' into p1 space. For a quick address overview: SDA> CLUE PROC/LAYOUT fwiw, Hein. ------------------------------ Date: 15 Aug 2008 13:20:44 -0500 From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) Subject: Re: DSPP & OpenVMS Message-ID: In article <7dd80f60808150605s20d1e47ei1f56b18f14405c9a@mail.gmail.com>, "Ken Robinson" writes: > > Have you looked at the HP Product Bulletin at > . > > It's a downloadable PC application that includes Quickspecs and > prices. I don't know if it works in the UK. > Now that link is interesting; I didn't know about that application. I'll give it a go next week. Thanks, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980's technology to a 21st century world ------------------------------ Date: Fri, 15 Aug 2008 15:45:12 -0400 From: JF Mezei Subject: Re: DSPP & OpenVMS Message-ID: <48a5dda6$0$1847$c3e8da3@news.astraweb.com> Mike R wrote: > As a longtime DEC (ex-)customer, and with some experience within Dec/ > Compaq/HP allow me to recommend: > > 1. Find the non-responsive person's manager > 2. Contact same > 3. If results are unsatisfactory, goto 1. Give up only after 3-4 > iterations. Isn't it simpler to just contact Sue and give her the info and let it flow from the top to the bottom instead of the other way around ? ------------------------------ Date: Fri, 15 Aug 2008 18:12:11 -0400 From: "William Webb" Subject: Re: DSPP & OpenVMS Message-ID: <8660a3a10808151512o12d4dfeage701b11f14cda95@mail.gmail.com> ------=_Part_82802_11885958.1218838331681 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Aug 15, 2008 at 10:12 AM, Richard B. Gilbert wrote: > Mike R wrote: > >> On Aug 15, 3:44 pm, clubley@remove_me.eisner.decus.org-Earth.UFP >> (Simon Clubley) wrote: >> >>> In article <00A7E234.2282A...@SendSpamHere.ORG>, VAXman- >>> @SendSpamHere.ORG writes: >>> >>> >> >>> Technical presales were excellent, but even though the sales people >>> within >>> HP have had the hard work done from them by the presales team, they still >>> can't be bothered to put together a quote for me, even though it's been >>> promised several times now. :-( >>> >>> >> As a longtime DEC (ex-)customer, and with some experience within Dec/ >> Compaq/HP allow me to recommend: >> >> 1. Find the non-responsive person's manager >> 2. Contact same >> 3. If results are unsatisfactory, goto 1. Give up only after 3-4 >> iterations. >> >> > Remember when you could just ask to speak with the "Manager on Duty"?? > Those were the "good old days"! > You still can, if you have the right level of support. I did it recently for the second time in almost twenty years. WWWebb ------=_Part_82802_11885958.1218838331681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Fri, Aug 15, 2008 at 10:12 AM, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
Mike R wrote:
On Aug 15, 3:44 pm, clubley@remove_me.eisner.decus.org-Earth.UFP
(Simon Clubley) wrote:
In article <00A7E234.2282A...@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:

<snip...>
Technical presales were excellent, but even though the sales people within
HP have had the hard work done from them by the presales team, they still
can't be bothered to put together a quote for me, even though it's been
promised several times now. :-(


As a longtime DEC (ex-)customer, and with some experience within Dec/
Compaq/HP allow me to recommend:

1. Find the non-responsive person's manager
2. Contact same
3. If results are unsatisfactory, goto 1. Give up only after 3-4
iterations.


Remember when you could just ask to speak with the "Manager on Duty"??
Those were the "good old days"!

You still can, if you have the right level of support.
 
I did it recently for the second time in almost twenty years.
 
WWWebb
------=_Part_82802_11885958.1218838331681-- ------------------------------ Date: Fri, 15 Aug 2008 21:39:10 -0400 From: "Richard B. Gilbert" Subject: Re: DSPP & OpenVMS Message-ID: <8_SdnYKDw6M2rTvVnZ2dnUVZ_oDinZ2d@comcast.com> William Webb wrote: > > > On Fri, Aug 15, 2008 at 10:12 AM, Richard B. Gilbert > > wrote: > > Mike R wrote: > > On Aug 15, 3:44 pm, clubley@remove_me.eisner.decus.org-Earth.UFP > (Simon Clubley) wrote: > > In article <00A7E234.2282A...@SendSpamHere.ORG>, VAXman- > @SendSpamHere.ORG writes: > > > > Technical presales were excellent, but even though the sales > people within > HP have had the hard work done from them by the presales > team, they still > can't be bothered to put together a quote for me, even > though it's been > promised several times now. :-( > > > As a longtime DEC (ex-)customer, and with some experience within > Dec/ > Compaq/HP allow me to recommend: > > 1. Find the non-responsive person's manager > 2. Contact same > 3. If results are unsatisfactory, goto 1. Give up only after 3-4 > iterations. > > > Remember when you could just ask to speak with the "Manager on Duty"?? > Those were the "good old days"! > > > You still can, if you have the right level of support. > The last time I tried, the person I was talking to hadn't a clue what I was talking about. H-P person rather than DEC/Compaq person. I eventually got through to someone who knew what I was talking about and was able to kick the right butts to get my problem solved. ------------------------------ Date: Fri, 15 Aug 2008 20:39:24 +0200 From: Wilm Boerhout Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <48a5cd61$0$6000$ba620dc5@text.nova.planet.nl> on 15-8-2008 17:45 Tom Linden wrote... [snip] > Why do you need macro? You could certainly do it with a small PL/I program > without any executable statements using the INITIAL attribute on the > declaration No compiler licenses other than COBOL on the system. It's not hobbyist. > External implies static, of course, which precludes reentrancy. If that > is an > issue you may need to rethink the design. This one static area holds variables filled at random time intervals, initiated by external events, by the main program. Every minute, the AST routine collects the variables from the static area and sends them away to a {screen/application/webserver, tbd} and zeroes the variables. No other agents work on the static area. Zeroing is done in the AST routine, and thus cannot be interrupted in user mode. Putting the variables into the area by the main program is shielded by a $SETAST (off,on) pair. If you can think of any other design for a main progam that runs synchronously since its inception, let me know. I've learned a lot in the past 48 hours, and am willing to learn more. -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Fri, 15 Aug 2008 20:44:15 +0200 From: Wilm Boerhout Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <48a5ce85$0$6030$ba620dc5@text.nova.planet.nl> on 14-8-2008 23:23 Richard Maher wrote... [snip] Reproducer program now works fine, with changes suggested by Richard & Hein &al.: - communication between main program and AST server routine is done via common AST area - condition value testing done via "is failure" construct. This removes my $SETAST error, cause of the ACCVIO - I/O from AST server routine not via DISPLAY (COB$xxx routines), but via separate channel to terminal and $QIO. Now on to build this into the original program! Thanks all. -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Fri, 15 Aug 2008 16:07:47 -0400 From: JF Mezei Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <48a5e2f3$0$1839$c3e8da3@news.astraweb.com> Wilm Boerhout wrote: > If you can think of any other design for a main progam that runs > synchronously since its inception, let me know. I've learned a lot in > the past 48 hours, and am willing to learn more. You can do a lot within an AST. But any IO should be done with $QIO and not higher level RTL. ($QIO does what it says: it queues an IO and does not wait). $QIOW in an AST is a no-no because if the IO doesn't complete, your program freezes and no other ASTs (such as important ASTs) can be delivered. If you want total freedom in code, then you AST can simply set some flag (variable = 1), then wake the mainline program. Mainline program then checks that variable, if it is set to 1, it performs the "execute every minute" code and sets the variable to 0, otherwise, it just performs the normal work. ------------------------------ Date: Fri, 15 Aug 2008 22:16:31 +0200 From: Wilm Boerhout Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <48a5e425$0$6014$ba620dc5@text.nova.planet.nl> on 15-8-2008 22:07 JF Mezei wrote... > Wilm Boerhout wrote: > >> If you can think of any other design for a main progam that runs >> synchronously since its inception, let me know. I've learned a lot in >> the past 48 hours, and am willing to learn more. > > > You can do a lot within an AST. But any IO should be done with $QIO and > not higher level RTL. ($QIO does what it says: it queues an IO and does > not wait). > > $QIOW in an AST is a no-no because if the IO doesn't complete, your > program freezes and no other ASTs (such as important ASTs) can be delivered. > > If you want total freedom in code, then you AST can simply set some flag > (variable = 1), then wake the mainline program. Mainline program then > checks that variable, if it is set to 1, it performs the "execute every > minute" code and sets the variable to 0, otherwise, it just performs the > normal work. This is useful JF. Hadn't thought about the QIOW not completing -as I said, AST's are new to me. But you said "wake the mainline program". It never hibernates, and sometime waits longer than a minute for an external event (mailbox reads, synchronously). It is important howver for the AST to report on minutes that have no activity (no counters accumulated). I have to think this through. -- Wilm Boerhout Zwolle, NL remove OLD PAINT from return address to reply ------------------------------ Date: Fri, 15 Aug 2008 18:31:06 -0400 From: JF Mezei Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <48a6048b$0$1807$c3e8da3@news.astraweb.com> Wilm Boerhout wrote: > This is useful JF. Hadn't thought about the QIOW not completing -as I > said, AST's are new to me. But you said "wake the mainline program". It > never hibernates, and sometime waits longer than a minute for an > external event (mailbox reads, synchronously). It is important howver > for the AST to report on minutes that have no activity (no counters > accumulated). I have to think this through. If your mainline can be stuck in an IO, then you'll need to do the "each minute" logic all inside the AST. In this case, you need to be careful how you do this. If this is to be done with TCPIP, I would recommend you use the $QIO interface. Not as pretty but will be better suited to AST driven logic. Note however, that one possible problem when you don't wait for completion is that if the pipe gets clogged (reader at other end is stuck or whatever), you will continue to send QIO and at one point, your QIO queue (BUFCNT) will be full and your QIO will either fail or get stuck waiting for space on the queue. In practice, this may or may not be a serious enough problem, but something to be aware of. Another possibility would be to have multi threaded approach. But not sure you'd want to do that in COBOL :-) There is a LOT of stuff that can be done inside an AST. Just remember that it will interrupt whatever code was executing in the mainline. There are some RTL routines that may not be re-entrant (aka: only one instance of that routine can execute in a process at a time). So if you can LIB$DO_SOMETHING in your mainline, you might not be able to call LIB$DO_SOMETHING in your AST. (the issue here is that you may not know exactly what COBOL does behind the scenes). Stuff like SYS$BINTIM , SYS$QIO etc are all pretty basic and work well inside ASTs. ------------------------------ Date: Fri, 15 Aug 2008 22:51:17 -0600 From: Jeff Campbell Subject: Re: Help needed with / confused by AST routine (VAX,COBOL) Message-ID: <1218861850_101@isp.n> Wilm Boerhout wrote: > on 15-8-2008 2:48 Jeff Campbell wrote... > [snip] > >> evaluate true >> when ss$_accvio >> display "Expiration time not readable" > > Jeff, I learn something new every day. Please explain the "evaluate > true" construction. How can comapring "true" with the condition codes do > the switching? COBOL never ceases to amaze me. > EVALUATE TRUE will check the state of the variable the 88 condition values are defined against. It's a shorthand way of saying: if return-status = ss$accvio then .... Jeff ----== 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: Fri, 15 Aug 2008 15:44:11 -0400 From: JF Mezei Subject: Re: NFS - OpenVMS to OpenVMS Message-ID: <48a5dd69$0$1847$c3e8da3@news.astraweb.com> If the move from alpha to that IA64 thing is an "event", then you can NFS, copy files over, verify they were copied properly and not truncated (careful with text files). But if the two boxes are to co-exist for a long time, clustering would be THE solution because you could then very safely maintain a single shared directory structure that is native to VMS, would support any/all VMS file organisations without worries and more importantly, the shared lockling means that you can work on both the alpha and that IA64 thing at the same time. ------------------------------ Date: Fri, 15 Aug 2008 16:37:41 -0400 From: "William Webb" Subject: Re: NFS - OpenVMS to OpenVMS Message-ID: <8660a3a10808151337t39dec025n14a602964640417e@mail.gmail.com> ------=_Part_81830_22344142.1218832661524 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, Aug 14, 2008 at 9:35 AM, Jan-Erik S=F6derholm < jan-erik.soderholm@telia.com> wrote: > Ingi wrote: > >> Hi all >> >> I'm working on migrating source code from Alpha to Itanium. The >> source code is in CMS on a single node Alpha. The new dev-env. Itanium >> will also be a single node. Both the Alpha and Itanium only have TCP/ >> IP installed, that is NO DECnet and that is not an option either (at >> least for now). >> >> I've been trying to NFS export the source-code-disk from the Alpha >> and mounting it on the Itanium. The TCP/IP Services versions are: >> >> HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 >> on an AlphaServer ES45 Model 2 running OpenVMS V8.2 >> >> HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - >> ECO 2 >> on an HP rx1620 (1.60GHz/3.0MB) running OpenVMS E8.3-1H1 >> >> On the Alpha I have the source-code disk mapped as '/src' and >> exported to the Itanium only. >> >> Pathname Logical File System >> /src ALPHA$DKB2: >> >> File System Host name >> /src ia64.somedomain >> >> I have a NFS proxy for my user and the system account as: >> VMS User_name Type User_ID Group_ID Host_name >> >> USER OND 40 2 ia64.somedomain >> SYSTEM OND 1 4 ia64.somedomain >> >> I only have proxies setup on the Alpha, it is sometimes mentioned in >> the documentation that proxies should be set up on the NFS-client side >> as well, but I haven't figured out why that should be neccessary. Both >> the NFS and PORTMAPPER server components are started on the Alpha and >> on the Itanium only the NFS Client client component is started. >> >> I'm mounting the source-code-disk using the following command: >> $tcpip mount src: src src: /path=3D"/src" /host=3Dalpha /structure=3D5 = / >> system >> >> OPCOM says: >> %%%%%%%%%%% OPCOM 14-AUG-2008 13:58:59.15 %%%%%%%%%%% >> Message from user TCPIP$NFS on ALPHA >> %TCPIP-S-NFS_MNTSUC, mounted file system /src >> -TCPIP-S-NFS_CLIENT, uid=3D40 gid=3D2 host_name =3D ia64.somedomain >> >> Now to my questions. >> >> 1) How can I get the same 'logical'/diskname on the client instead >> of new DNFSn: at every mount ? (I've tried /PROCESSOR=3DSAME:DNFS20 >> without success) >> >> 2) Has anyone similar setup and is will to share setup hints etc ? >> >> 3) I've also been trying to mount the disk onto Linux but I always >> get the 'permission' denied when accessing the mount. The mountpoint >> on Linux looks like: >> 'drwxr-x--x 2 nobody nogroup 512 2008-08-14 13:07 src/' >> >> I have had a proxy setup for my Linux user but the 'uid' has always >> showed up as 0 in OPCOM. >> >> %%%%%%%%%%% OPCOM 13-AUG-2008 19:47:56.98 %%%%%%%%%%% >> Message from user TCPIP$NFS on ALPHA >> %TCPIP-S-NFS_MNTSUC, mounted file system /src >> -TCPIP-S-NFS_CLIENT, uid=3D0 gid=3D1002 host_name =3D linux.somedomain >> >> USER OND 1001 1002 >> linux.somedomain >> >> From /etc/fstab >> alpha:/src /mnt/alpha/src nfs >> rw,user,rsize=3D8192,wsize=3D8192,nolock,proto=3Dudp,hard,intr,nfsvers= =3D3 0 0 >> >> Has anyone a workaround for that ? >> >> 4) I've been reading chapter 22 (NFS Server) and chapter 23 (NFS >> Client) atleast a dozen times, but I dont seem to be able to >> understand the 'noproxy_id/noproxy_gid' stuff. I someone willing to >> share some light on that. >> >> Regards >> - Ingi >> >> >> > > Maybe it's better if you tell us *why* you need this NFS setup. > > Is it just during he migration period ? Then you could > make a plain copy (BACKUP/ZIP/FTP), setup your I64 > environment and make a final copy when you "switch". > > Or are you going to develop for both platforms using the > same sources ? Then I guess that a "real" cluster setup > will give you much better functionality then NFS. > > Or maybe you need to run the migration and new Alpha > development concurently ? Then I guess that a cluster > setup still is the best way. > > Note that NFS lacks a lot whan it comes to e.g. locking. > I agree with Jan-Erik. NFS is not a filesystem I trust the way I trust the ODS's. We use an NFS share (on an EMC Celera box) to store our patch and product kits so they're pretty much available anywhere. And, being of a somewhat less that trusting nature when it comes to NFS, I have the collections of patches (for example) backed up into a saveset whic= h is zipped into a zip file, and made into a self-extracting executable with SFX_AXP.EXE. WWWebb ------=_Part_81830_22344142.1218832661524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


On Thu, Aug 14, 2008 at 9:35 AM, Jan-Erik S=F6de= rholm <jan-erik.soderholm@telia.com> wrote:
Ingi wrote:
Hi all

 I'm work= ing on migrating source code from Alpha to Itanium. The
source code is i= n CMS on a single node Alpha. The new dev-env. Itanium
will also be a single node. Both the Alpha and Itanium only have TCP/
IP= installed, that is NO DECnet and that is not an option either (at
least= for now).

 I've been trying to NFS export the source-code-= disk from the Alpha
and mounting it on the Itanium. The TCP/IP Services versions are:

&n= bsp;HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1
 on a= n AlphaServer ES45 Model 2 running OpenVMS V8.2

 HP TCP/IP Serv= ices for OpenVMS Industry Standard 64 Version V5.6 -
ECO 2
 on an HP rx1620  (1.60GHz/3.0MB) running OpenVMS E8.3-1= H1

 On the Alpha I have the source-code disk mapped as '/sr= c' and
exported to the Itanium only.

 Pathname   &n= bsp;                     =        Logical File System
 /src                   &= nbsp;                    =   ALPHA$DKB2:

 File System         &n= bsp;                   Host na= me
 /src                 &n= bsp;                     =    ia64.somedomain

 I have a NFS proxy for my user an= d the system account as:
 VMS User_name     Type      User_ID   &= nbsp;Group_ID   Host_name

 USER        = ;      OND            40  = ;         2   ia64.somedomain
 SYSTEM &nbs= p;        OND            = 1           4    ia64.somedomain
 I only have proxies setup on the Alpha, it is sometimes mentioned in=
the documentation that proxies should be set up on the NFS-client side
a= s well, but I haven't figured out why that should be neccessary. Boththe NFS and PORTMAPPER server components are started on the Alpha and
on the Itanium only the NFS Client client component is started.

&nbs= p;I'm mounting the source-code-disk using the following command:
&nb= sp;$tcpip mount src: src src: /path=3D"/src" /host=3Dalpha /struc= ture=3D5 /
system

 OPCOM says:
%%%%%%%%%%%  OPCOM  14-AUG-200= 8 13:58:59.15  %%%%%%%%%%%
Message from user TCPIP$NFS on ALPHA
= %TCPIP-S-NFS_MNTSUC, mounted file system /src
-TCPIP-S-NFS_CLIENT, uid= =3D40 gid=3D2 host_name =3D ia64.somedomain

 Now to my questions.

 1) How can I get the same '= logical'/diskname on the client instead
of new DNFSn: at every mount= ? (I've tried /PROCESSOR=3DSAME:DNFS20
without success)

&nbs= p;2) Has anyone similar setup and is will to share setup hints etc ?

 3) I've also been trying to mount the disk onto Linux but I a= lways
get the 'permission' denied when accessing the mount. The = mountpoint
on Linux looks like:
 'drwxr-x--x 2 nobody nogrou= p 512 2008-08-14 13:07 src/'

 I have had a proxy setup for my Linux user but the 'uid' = has always
showed up as 0 in OPCOM.

%%%%%%%%%%%  OPCOM  = ;13-AUG-2008 19:47:56.98  %%%%%%%%%%%
Message from user TCPIP$NFS o= n ALPHA
%TCPIP-S-NFS_MNTSUC, mounted file system /src
-TCPIP-S-NFS_CLIENT, uid=3D0 gid=3D1002 host_name =3D linux.somedomain
<= br> USER              OND   &n= bsp;        1001           100= 2
linux.somedomain

 From /etc/fstab
alpha:/src /mnt/alpha= /src nfs
rw,user,rsize=3D8192,wsize=3D8192,nolock,proto=3Dudp,hard,intr,= nfsvers=3D3 0 0

 Has anyone a workaround for that ?

 4) I've been = reading chapter 22 (NFS Server) and chapter 23 (NFS
Client) atleast a do= zen times, but I dont seem to be able to
understand the 'noproxy_id/= noproxy_gid' stuff. I someone willing to
share some light on that.

 Regards
- Ingi




Maybe it's better if you tell us *why* you ne= ed this NFS setup.

Is it just during he migration period ? Then you = could
make a plain copy (BACKUP/ZIP/FTP), setup your I64
environment and make = a final copy when you "switch".

Or are you going to develo= p for both platforms using the
same sources ? Then I guess that a "= real" cluster setup
will give you much better functionality then NFS.

Or maybe you need = to run the migration and new Alpha
development concurently ? Then I gues= s that a cluster
setup still is the best way.

Note that NFS lacks= a lot whan it comes to e.g. locking.

 
I agree with Jan-Erik. 
 
NFS is not a filesystem I trust the way I trust the ODS's.
 
We use an NFS share (on an EMC Celera box) to store our patch and prod= uct kits so they're pretty much available anywhere.
 
And, being of a somewhat less that trusting nature when it comes to NF= S, I have the collections of patches (for example) backed up into a saveset= which is zipped into a zip file, and made into a self-extracting executabl= e with SFX_AXP.EXE.

WWWebb
 
 
------=_Part_81830_22344142.1218832661524-- ------------------------------ Date: Fri, 15 Aug 2008 15:52:05 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: OT: noVMS Alphas... Message-ID: <87470b0a-3f0d-4b1a-95d1-063c4dc4cb21@56g2000hsm.googlegroups.com> On Aug 15, 6:32 pm, moro...@world.std.spaamtrap.com (Michael Moroney) wrote: > johnwalla...@yahoo.co.uk writes: > >> Don't try this with an XL266. They actually crippled the 21064A cpu so you > >> could load SRM. > >Not entirely correct. The Celebris XL266 (or whatever they called the > >PCBU variant of the AlphaStation 400) had a "half flash", big enough > >to hold AlphaBIOS *or* SRM console, but not both at the same time. If > >you could reflash it, you could change OS and it work work (assuming > >the graphics, SCSI, etc worked under both OSes). > > They also did this with the Alphastation 200s, all but the early ones. > You had to reflash to go between SRM and AlphaBIOS. I believe they > provided sockets on the board so you could add the flash chips if you > wanted to. > > >There were crippled Alpha CPU chips, e.g. some of the 21164/EV5 chips > >licenced by Samsung, maybe 21164PC, can't remember, which reportedly > >had a VMS-specific memory management component missing (again, I can't > >remember exactly what). This meant they could run NT, or could run > >Tru64 (and SRM underneath), but could not ever run VMS. > > Also the Alpha 21066 chip. http://h71000.www7.hp.com/wizard/wiz_2406.html The 21066 had its challenges, but architectural inability to run VMS wasn't one of them. It was a 21064/EV4-class core with all the usually- external glue logic (today's "northbridge, southbridge") on the same chip, which was intended to make it trivially easy to build into PCs and "embedded" systems (just add DRAM and PCI peripherals). Things didn't work out quite right though, and the performance of a 21066 at 166MHz was noticeably worse than a 21064 at 150MHz. The simple integration and low power design means the 21066 is in the Tadpole Alphabook, on which VMS was supported, and in the Alpha Multia, where you have to refer to the FAQ to find out how to get it to run VMS. Slowly. HP still have a subset of chip info, covering some EV4 stuff (21064, 21066) and some EV5 stuff (including 21164PC and PC164SX docs) at http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html I've got an Alpha Multia gathering dust in addition to the previously mentioned PC164SX. Due to circumstances which won't become clear again for some time, the case has an Intel Inside sticker, and Multia Intel part numbering, but the innards are Alpha. All offers gratefully received. ------------------------------ End of INFO-VAX 2008.446 ************************