INFO-VAX Fri, 22 Aug 2008 Volume 2008 : Issue 459 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: Info on SOA, TOGAF, Virtualisation, SaaS etc. Re: lib$find_file on Pascal Re: lib$find_file on Pascal OpenVMS patches - FTP site Re: OpenVMS patches - FTP site Re: OpenVMS patches - FTP site SAS 9.2 on HP OpenVMS Integrity Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue Re: strange tcpip issue ---------------------------------------------------------------------- Date: Fri, 22 Aug 2008 10:18:29 +0200 From: "P. Sture" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <00A7E754.2E08253C@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > In article > <6f1e8270-77f4-4751-933e-8fea364db716@e53g2000hsa.googlegroups.com>, Neil > Rieck writes: > >So rather than read all 360 messages in this thread, can somebody > >answer the following question: Did anyone at DEFCON16 cause anything > >more than a stack dump? Was anyone able to inject a useful new PC > >address then hijack a VMS system? > > YES! It's very real and several here, including myself, have coded our > own proof of concept hacks. I liked Roger Ivie's summary of the problem: http://preview.tinyurl.com/55bn28 "The whole point is that the PC at which the ACCVIO occurred is 0x40404040. In other words, a privileged program jumped to an address he typed in. All it takes is to arrange nasty code living at an address you can type in and it will be executed." -- Paul Sture ------------------------------ Date: Fri, 22 Aug 2008 07:50:11 -0400 From: "John Reagan" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <3_GdnfO7pft1OjPVnZ2dnUVZ_uydnZ2d@earthlink.com> "P. Sture" wrote in message news:paul.sture.nospam-> "The whole point is that the PC at which the ACCVIO occurred is > 0x40404040. In other words, a privileged program jumped to an address he > typed in. All it takes is to arrange nasty code living at an address you > can type in and it will be executed." > I thought I posted this to the newsgroup, but I may have hit "reply" vs "reply group". [I'm using a new newsreader] You can't do this on I64. The compilers don't save the return PC, previous stack pointer, etc. on the memory stack but put them into high stacked registers instead. Yes, those registers may eventually get spilled out to the register backing store, but that isn't anywhere near the memory stack. All you can do on I64 is overwrite your own data. Pro: You can't use a bufferover write to change the return address. Con: On Alpha, overwriting your return address produces "badness" at the routine exit. On I64, you may never realize you have overwritten your own data or when you do, it may be hard to figure out the guilty party. John Reagan ------------------------------ Date: Fri, 22 Aug 2008 05:00:12 -0700 (PDT) From: Neil Rieck Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <788080f9-afd0-42a0-9620-1cd4781629ae@m44g2000hsc.googlegroups.com> On Aug 22, 4:18=A0am, "P. Sture" wrote: > In article <00A7E754.2E082...@SendSpamHere.ORG>, > =A0VAXman- =A0@SendSpamHere.ORG wrote: > > > In article > > <6f1e8270-77f4-4751-933e-8fea364db...@e53g2000hsa.googlegroups.com>, Ne= il > > Rieck writes: > > >So rather than read all 360 messages in this thread, can somebody > > >answer the following question: Did anyone at DEFCON16 cause anything > > >more than a stack dump? Was anyone able to inject a useful new PC > > >address then hijack a VMS system? > > > YES! =A0It's very real and several here, including myself, have coded o= ur > > own proof of concept hacks. > > I liked Roger Ivie's summary of the problem: > > =A0http://preview.tinyurl.com/55bn28 > > "The whole point is that the PC at which the ACCVIO occurred is > 0x40404040. In other words, a privileged program jumped to an address he > typed in. All it takes is to arrange nasty code living at an address you > can type in and it will be executed." > > -- > Paul Sture I guess that was the point of my question. I understand the problem, and have seen a few stack dumps, but was wondering if anyone had actually demonstrated something like a complete system take over. p.s. I'm not trying to say there is no problem here. The fact that there are ANY buffer overflows makes me very nervous. p.s.-2 For anyone wishing to see how these exploits are coded, check out P. 119 of the second edition of "Hacking" from "No Starch Press". Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/ ------------------------------ Date: Fri, 22 Aug 2008 05:40:04 -0700 (PDT) From: bugs@signedness.org Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <52e86f7e-b7c1-467d-bd86-4591b6e901d2@x41g2000hsb.googlegroups.com> On Aug 22, 12:50=A0pm, "John Reagan" wrote: > "P. Sture" wrote in message > > news:paul.sture.nospam-> "The whole point is that the PC at which the ACC= VIO > occurred is > > > 0x40404040. In other words, a privileged program jumped to an address h= e > > typed in. All it takes is to arrange nasty code living at an address yo= u > > can type in and it will be executed." > > I thought I posted this to the newsgroup, but I may have hit "reply" vs > "reply group". =A0[I'm using a new newsreader] > > You can't do this on I64. =A0The compilers don't save the return PC, prev= ious > stack pointer, etc. on the memory stack but put them into high stacked > registers instead. =A0Yes, those registers may eventually get spilled out= to > the register backing store, but that isn't anywhere near the memory stack= . > All you can do on I64 is overwrite your own data. > > Pro: You can't use a bufferover write to change the return address. > > Con: On Alpha, overwriting your return address produces "badness" at the > routine exit. =A0On I64, you may never realize you have overwritten your = own > data or when you do, it may be hard to figure out the guilty party. > > John Reagan I'm not familiar with Itanium (When we looked VMS exploitation we only had access to VAX and Alpha boxes) so it is hard for me to comment on what you wrote. Even if the function return addresses are never "flushed out to a stack" or end up at a different location, in a lot of cases being able to overwrite local variables on the stack would be enough to take control over the program without touching a saved return address.. Is there anything stopping you from overwriting previous frames too? ------------------------------ Date: 22 Aug 2008 07:45:56 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <6h5c4rFjdi7iU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: > > You are not by any chance refering to "Safe-C" which was available for > the PDP-11 under Unix and other OSes as far back as the 70's, were you? :-) Safe-C, or SAFEC, or some similar name and I don't know of all the things they did that made it "safe". > I have often wondered what the chances of finding anyone from the company > were. Keep looking. I just read thier adds. >> There is nothing in the standard >> that makes it necessary to add the extra safety. > > And also nothing in th the standard that says you can't. While I, > personally, don't see all the problems with C as real problems > (probably because of my software development training and experience > don't lend themselves to making the kinds of mistakes that are so > prevalent today) I can see where there should be a market for > something like "Safe-C" today. Of course, it wasn't ANSI!! :-) I would consider it a wonderfull upgrade to the standard if there was something added that said vendors must! And back in the days of Safe-C, many compilers weren't ANSI. > >> >> For VMS, only IA-64 enforces no-execution of stack space. > > I have always been amazed that more kernels don't implement this. Another > is allowing execution from the Unix /tmp (or any directory that is world > writable). No kernel can implement this without underlying hardware support. IA-64 is the only hardware that I know provides it, although I hope there are others. Of course, even with underlying hardware support, the kernel also has to support it. How many kernels run on IA-64 and don't support it? ------------------------------ Date: 22 Aug 2008 07:46:51 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <6f1e8270-77f4-4751-933e-8fea364db716@e53g2000hsa.googlegroups.com>, Neil Rieck writes: > So rather than read all 360 messages in this thread, can somebody > answer the following question: Did anyone at DEFCON16 cause anything > more than a stack dump? Was anyone able to inject a useful new PC > address then hijack a VMS system? Elevation of privilege of an authorized user was caused. Access to unauthorized users was not. ------------------------------ Date: 22 Aug 2008 13:24:39 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6h7t0nFjm91gU1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <6h5c4rFjdi7iU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >> >> You are not by any chance refering to "Safe-C" which was available for >> the PDP-11 under Unix and other OSes as far back as the 70's, were you? :-) > > Safe-C, or SAFEC, or some similar name and I don't know of all the > things they did that made it "safe". I stil have my PDP-11 software library books (a two volume set!) I'll post what it says over the weekend. > >> I have often wondered what the chances of finding anyone from the company >> were. > > Keep looking. I just read thier adds. Might be fun to play with if the owners were no longer interested in it as a product and were willing to release it. > >>> There is nothing in the standard >>> that makes it necessary to add the extra safety. >> >> And also nothing in th the standard that says you can't. While I, >> personally, don't see all the problems with C as real problems >> (probably because of my software development training and experience >> don't lend themselves to making the kinds of mistakes that are so >> prevalent today) I can see where there should be a market for >> something like "Safe-C" today. Of course, it wasn't ANSI!! :-) > > I would consider it a wonderfull upgrade to the standard if there was > something added that said vendors must! I am against forcing anything additional on the language as you will see in a minute. :-) But adding stuff tot he compiler as an option is fine. Sometimes the overhead is not worth the potential gain. If the programmer has gone tot he trouble of ensuring there are no buffer overflows why saddle the executable with unneccessary code to look for them? > > And back in the days of Safe-C, many compilers weren't ANSI. Sorry, that was a kind of tongue-in-cheek remark as I still think of C as what K&R wrote and not what ANSI wrote. They should have called theirs "D". > >> >>> >>> For VMS, only IA-64 enforces no-execution of stack space. >> >> I have always been amazed that more kernels don't implement this. Another >> is allowing execution from the Unix /tmp (or any directory that is world >> writable). > > No kernel can implement this without underlying hardware support. > IA-64 is the only hardware that I know provides it, although I hope > there are others. > > Of course, even with underlying hardware support, the kernel also has > to support it. How many kernels run on IA-64 and don't support it? I am not so sure about the hardware requirement. I thought this was one of the "features" that NSA put into Linux in what is now called SELinux. I have never understood why these features were never made part of the base Linux Kernel except to once again fall back on my claim of apathy on the part of the users and developers. I can understand this with Linux, but I really fail to understand why the BSD camps have not taken the information and research provided by NSA and implemented it in BSD. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Fri, 22 Aug 2008 09:57:24 -0400 From: "Richard B. Gilbert" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6fidnVnryqhUWDPVnZ2dnUVZ_tfinZ2d@comcast.com> Bill Gunshannon wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >> In article <6h5c4rFjdi7iU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>> You are not by any chance refering to "Safe-C" which was available for >>> the PDP-11 under Unix and other OSes as far back as the 70's, were you? :-) >> Safe-C, or SAFEC, or some similar name and I don't know of all the >> things they did that made it "safe". > > I stil have my PDP-11 software library books (a two volume set!) I'll > post what it says over the weekend. > >>> I have often wondered what the chances of finding anyone from the company >>> were. >> Keep looking. I just read thier adds. > > Might be fun to play with if the owners were no longer interested in it > as a product and were willing to release it. > >>>> There is nothing in the standard >>>> that makes it necessary to add the extra safety. >>> And also nothing in th the standard that says you can't. While I, >>> personally, don't see all the problems with C as real problems >>> (probably because of my software development training and experience >>> don't lend themselves to making the kinds of mistakes that are so >>> prevalent today) I can see where there should be a market for >>> something like "Safe-C" today. Of course, it wasn't ANSI!! :-) >> I would consider it a wonderfull upgrade to the standard if there was >> something added that said vendors must! > > I am against forcing anything additional on the language as you will see > in a minute. :-) But adding stuff tot he compiler as an option is fine. > Sometimes the overhead is not worth the potential gain. If the programmer > has gone tot he trouble of ensuring there are no buffer overflows why > saddle the executable with unneccessary code to look for them? > >> And back in the days of Safe-C, many compilers weren't ANSI. > > Sorry, that was a kind of tongue-in-cheek remark as I still think of C > as what K&R wrote and not what ANSI wrote. They should have called theirs > "D". > >>>> For VMS, only IA-64 enforces no-execution of stack space. >>> >>> I have always been amazed that more kernels don't implement this. Another >>> is allowing execution from the Unix /tmp (or any directory that is world >>> writable). >> No kernel can implement this without underlying hardware support. >> IA-64 is the only hardware that I know provides it, although I hope >> there are others. >> >> Of course, even with underlying hardware support, the kernel also has >> to support it. How many kernels run on IA-64 and don't support it? > > I am not so sure about the hardware requirement. I thought this was one > of the "features" that NSA put into Linux in what is now called SELinux. > I have never understood why these features were never made part of the > base Linux Kernel except to once again fall back on my claim of apathy > on the part of the users and developers. I can understand this with > Linux, but I really fail to understand why the BSD camps have not taken > the information and research provided by NSA and implemented it in BSD. > > bill > > > Some people are using an O/S to get some work done. Others are having fun playing with it. Those who are trying to get some work done may install the NSA fixes or pay someone to do so. Those who are playing with the O/S have little or no incentive. ------------------------------ Date: Fri, 22 Aug 2008 10:26:22 -0400 From: "John Reagan" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: wrote in message news:52e86f7e-b7c1-467d-bd86-4591b6e901d2@x41g2000hsb.googlegroups.com... I'm not familiar with Itanium (When we looked VMS exploitation we only had access to VAX and Alpha boxes) so it is hard for me to comment on what you wrote. Even if the function return addresses are never "flushed out to a stack" or end up at a different location, in a lot of cases being able to overwrite local variables on the stack would be enough to take control over the program without touching a saved return address.. Is there anything stopping you from overwriting previous frames too? You can certainly overwrite local variables on your frame (or earlier frames) if you wish. It is all writeable stack. It just MUCH harder to find and overwrite the saved return PC. John Reagan ------------------------------ Date: Fri, 22 Aug 2008 14:38:18 GMT From: gerry77@no.spam.mail.com Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <18jta495lf6vdgoqlcjjjc1hpcrh5nv94t@4ax.com> On 20 Aug 2008 07:39:33 -0500, koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > 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. Now that Alpha and Itanium patches were published, I'm in doubt: might I hope that in the next few days/weeks we'll also see those much needed VAX patches or should I start to be sad and resigned? :-P ... I know, I'm a dreamer! G. ------------------------------ Date: Fri, 22 Aug 2008 18:23:21 +0200 From: "P. Sture" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <3_GdnfO7pft1OjPVnZ2dnUVZ_uydnZ2d@earthlink.com>, "John Reagan" wrote: > "P. Sture" wrote in message > news:paul.sture.nospam-> "The whole point is that the PC at which the ACCVIO > occurred is > > 0x40404040. In other words, a privileged program jumped to an address he > > typed in. All it takes is to arrange nasty code living at an address you > > can type in and it will be executed." > > > > I thought I posted this to the newsgroup, but I may have hit "reply" vs > "reply group". [I'm using a new newsreader] > Yes, that message came through. It's at: http://preview.tinyurl.com/6qrstq > You can't do this on I64. The compilers don't save the return PC, previous > stack pointer, etc. on the memory stack but put them into high stacked > registers instead. Yes, those registers may eventually get spilled out to > the register backing store, but that isn't anywhere near the memory stack. > All you can do on I64 is overwrite your own data. > > Pro: You can't use a bufferover write to change the return address. > > Con: On Alpha, overwriting your return address produces "badness" at the > routine exit. On I64, you may never realize you have overwritten your own > data or when you do, it may be hard to figure out the guilty party. > > John Reagan -- Paul Sture ------------------------------ Date: Fri, 22 Aug 2008 06:46:36 -0700 (PDT) From: sampsal@gmail.com Subject: Re: Info on SOA, TOGAF, Virtualisation, SaaS etc. Message-ID: On Aug 21, 11:50=A0am, anaz wrote: > Hi all, > > I recently moved south to Bangalore and I am working for a large > implementing virtualisation and/or SaaS in our company. > > [blah...blah...blah] > > All the help that group members can provide in this regard is much > appreciated. > > Thanks, > Anaz We at AssCo has revolutionized the concept of media sourcing. Our technology takes the best aspects of ActionScript and SMIL. We have come to know that it is better to streamline holistically than to innovate perfectly. The subscriber communities factor can be summed up in one word: front-end. It comes off as fabulous, but it's true! Think virtual. Think innovative. Think ubiquitous. But don't think all three at the same time. We will syndicate the term "dynamic". What does the buzzword "deliverables" really mean? If you target virtually, you may have to innovate magnetically. Do you have a plan of action to become visionary? Our feature set is unparalleled, but our bricks-and-clicks infomediaries and newbie-proof use is invariably considered a remarkable achievement. Think micro-killer. See http://www.andrewdavidson.com/gibberish/ for more details! Regards, Sampsa ------------------------------ Date: Fri, 22 Aug 2008 00:06:41 -0700 (PDT) From: Ramon Jimenez Subject: Re: lib$find_file on Pascal Message-ID: <80e0530c-f794-41c0-b021-6a2fd899a1d9@c58g2000hsc.googlegroups.com> On Aug 20, 8:20=A0pm, "John Reagan" wrote: > OK, make up your mind. =A0Here or there... ? > > You didn't get enough information on how "dummy" is declared. =A0VARYING = OF > CHAR? =A0PACKED ARRAY OF CHAR? > > You also didn't say where you got the prototype of LIB$FIND_FILE from? > SYS$LIBRARY:PAS$LIB_ROUTINES? =A0Your private version? > > Here's an example that works: > > [inherit('sys$library:starlet', > =A0 =A0 =A0 =A0 =A0'sys$library:pascal$lib_routines')] > program find_file(input,output); > > var > =A0 =A0 file_spec : varying [132] of char; > =A0 =A0 result_spec : varying [132] of char; > =A0 =A0 context : unsigned; > =A0 =A0 ret_stat : unsigned; > > begin > context :=3D 0; > > write('Enter filespec to parse: '); > while not eof do > =A0 =A0 =A0 =A0 begin > > =A0 =A0 =A0 =A0 { Read the filespec from the user } > =A0 =A0 =A0 =A0 readln(file_spec); > > =A0 =A0 =A0 =A0 { Loop and parse the file spec } > =A0 =A0 =A0 =A0 repeat > > =A0 =A0 =A0 =A0 =A0 =A0 { Parse it... } > =A0 =A0 =A0 =A0 =A0 =A0 ret_stat :=3D lib$find_file( > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 file_spec, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 %descr result_spec, { Use %DESCR to get C= LASS_VS } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 context); > > =A0 =A0 =A0 =A0 =A0 =A0 if (not odd(ret_stat)) and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ret_stat <> RMS$_NMF) and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ret_stat <> RMS$_FNF) > =A0 =A0 =A0 =A0 =A0 =A0 then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lib$stop(ret_stat); > > =A0 =A0 =A0 =A0 =A0 =A0 if (ret_stat <> RMS$_NMF) and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(ret_stat <> RMS$_FNF) > =A0 =A0 =A0 =A0 =A0 =A0 then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 writeln(result_spec); > > =A0 =A0 =A0 =A0 until (ret_stat =3D RMS$_NMF) or (ret_stat =3D RMS$_FNF); > > =A0 =A0 =A0 =A0 { Clear LIB$FIND_FILE context } > =A0 =A0 =A0 =A0 lib$find_file_end(context); > > =A0 =A0 =A0 =A0 { Get another file spec } > =A0 =A0 =A0 =A0 write('Enter filespec to parse: '); > > =A0 =A0 =A0 =A0 end; > end. > > Note the explicit use of %DESCR on the output argument for LIB$FIND_FILE. > > John Thank you the explicit use of %DESCR worked. Xoutfile was defined as varyng and dummy as packed array, my first guess was to align both definition, but I got compilation errors. Xoutfile and dummy were defined on different sections of the code, so I move and put them together, I also set context to zero begin execution. After that seems that it works properly. Thank you all for your help ------------------------------ Date: Fri, 22 Aug 2008 07:55:12 -0400 From: "John Reagan" Subject: Re: lib$find_file on Pascal Message-ID: "Ramon Jimenez" wrote in message news:80e0530c-f794-41c0-b021- Thank you the explicit use of %DESCR worked. Excellent. For those of you keeping score at home, here is what happened: The prototype that comes in PASCAL$LIB_ROUTINES has the output string defined as a PACKED ARRAY OF CHAR. Even when passing a VARYING to it, the compiler would have generated a CLASS_S fixed-length descriptor for the body. So when LIB$FIND_FILE wrote the result, it wrote the whole body and didn't know to write into the length word. Using %DESCR on an actual parameter overrides the formal definition. %DESCR generates the appropriate descriptor for the actual parameter, in this case, a VARYING string. Now with a CLASS_VS descriptor, LIB$FIND_FILE (actually some STR$COPY or some such) knows to update the body AND the length word. The variable now has the correct result WITH the correct length. John Reagan ------------------------------ Date: Fri, 22 Aug 2008 13:58:02 GMT From: "Colin Butcher" Subject: OpenVMS patches - FTP site Message-ID: Start at: ftp.itrc.hp.com using anonymous FTP. The "/openvms_patches" directory should have what you need, split out by hardware type and OS version. -- Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: Fri, 22 Aug 2008 14:01:25 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: OpenVMS patches - FTP site Message-ID: Colin Butcher wrote: > Start at: ftp.itrc.hp.com using anonymous FTP. The "/openvms_patches" > directory should have what you need, split out by hardware type and OS > version. > I thought of pointing to that one, but I wasn't sure if the TCPIP "patches" where full kits or not... ------------------------------ Date: Fri, 22 Aug 2008 09:35:54 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: OpenVMS patches - FTP site Message-ID: <08082209355445_20200494@antinode.info> From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm? > Colin Butcher wrote: > > Start at: ftp.itrc.hp.com using anonymous FTP. The "/openvms_patches" > > directory should have what you need, split out by hardware type and OS > > version. > > I thought of pointing to that one, but I wasn't sure if > the TCPIP "patches" where full kits or not... One seems to be: alp $ prod show prod /full *tcp* ------------------------------------ ----------- --------- ------------------------------------ ------------------------------------ PRODUCT KIT TYPE STATE MAINTENANCE REFERENCED BY ------------------------------------ ----------- --------- ------------------------------------ ------------------------------------ DEC AXPVMS TCPIP V5.4-15ECO7 Full LP Installed DEC AXPVMS OPENVMS V7.3-2 ------------------------------------ ----------- --------- ------------------------------------ ------------------------------------ ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Fri, 22 Aug 2008 13:04:45 +0000 From: "Main, Kerry" Subject: SAS 9.2 on HP OpenVMS Integrity Message-ID: <9D02E14BC0A2AE43A5D16A4CD8EC5A593ED5DE59E2@GVW1158EXB.americas.hpqcorp.net> All, The readers of this list might be interested in the following announcement: [Please note that Sue would really like to see as many of you as possible a= ttending this event] :) +++++++++++ SAS delivers SAS 9.2 on HP OpenVMS Integrity Servers - hear what's new! You're invited to attend a joint HP / SAS Webinar to learn about this power= ful combination of hardware and software. SAS, as the leader in business analytics software and services, is the firs= t company to call when you need to solve complex business problems, achieve key objectives an= d more effectively manage your information assets. As you may now know, SAS recently delivered the SAS 9.2 (Foundation) produc= ts on OpenVMS for HP Integrity Servers. Many of our customers have been eagerly a= waiting this release and are very excited - hear why. Join us and learn about HP's roadmap for OpenVMS and the exciting new featu= res already available in the latest release and plans for future releases. OpenVMS on HP Integrity Servers provides an exciting combination of flexibi= lity, lower TCO (total cost of ownership), and help IT Managers do more with less. The webinar will cover topics: * SAS 9.2 - what is new and how you can benefit * Benefits of HP Integrity servers * OpenVMS Strategy and Directions * How to move from Alpha to Integrity * Resources available to help The one hour webinar is planned for 10-Sep-08 at 12:00 pm EDT (Boston Time = UTC/GMT -5 hours) - mark your calendar now! To register, please go to: http://h71000.www7.hp.com/SAS_OpenVMS_webinar_form.html You will receive an email with instructions on how to connect to the webina= r. If you have any questions, please contact John.Egolf@hp.com or Ephraim.Peak@sas.com We're looking forward to meeting with you. ------------------------------ Date: Fri, 22 Aug 2008 02:32:52 -0400 From: "William Webb" Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: <8660a3a10808212332l175cff80se7c1f91ed2d8b04f@mail.gmail.com> On Thu, Aug 21, 2008 at 9:18 PM, wrote: > FWIW, reading the patch description text (Yes, with my specs on), there > is nothing to indicate the severity of or need for applying this patch! > I'd wager that there are sites that will NEVER install this patch unless > they see some buffer overflow in SMG. Unless this patch is listed as a > SECURITY patch, people not following what has been going on here for the > better part of a week will not install 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. > At the risk of sounding sarcastic. Dude, it's a "1". That ought to tell you something. However I will complain that the description of the "problem" in the release notes is severely innocuous. If I ran the zoo, I'd have made this a MUP. WWWebb ------------------------------ Date: Fri, 22 Aug 2008 11:00:48 +0200 From: "P. Sture" Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: In article <00A7E6FD.4C4C2D30@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > I see the eye doctor readily to check for diabetic retinopathy. About 2 > years ago I was written a prescription for specs; I only recently filled > it. I'm still getting used to wearing them. I wake every morning, get a > cup of coffee and venture down to the VAXcave forgetting to grab them off > of the dresser where I perch them the night before. Maybe I'll start to > take them off at my desk in the eve and leave them there. I've already had specs for a couple of decades for long distance work, in essence for driving, reading presentations when at the back of a room, and so on. I recall that it did take a while to get into the habit of remembering to take them with me. I'd definitely recommend getting a spare pair, not only as a counter for forgetfulness, but in case of a system failure (in my case the unexpected chewing of my first pair by a puppy!). -- Paul Sture ------------------------------ Date: 22 Aug 2008 07:49:09 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: In article <00A7E75B.E1A3D903@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes: > FWIW, reading the patch description text (Yes, with my specs on), there > is nothing to indicate the severity of or need for applying this patch! > I'd wager that there are sites that will NEVER install this patch unless > they see some buffer overflow in SMG. Unless this patch is listed as a > SECURITY patch, people not following what has been going on here for the > better part of a week will not install it. Yes. the rating is INSTAL_1, but it should be a MUP! ------------------------------ Date: Fri, 22 Aug 2008 06:01:57 -0700 (PDT) From: FrankS Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: On Aug 22, 5:00=A0am, "P. Sture" wrote: > I'd definitely recommend getting a spare pair, not only as a counter for > forgetfulness, but in case of a system failure (in my case the > unexpected chewing of my first pair by a puppy!). WalMart, K-Mart, and their ilk are your friend in this particular case. I've got 6 pairs of very cheap ($6 - $12) reading glasses scattered around the house and car. I even have one pair expressly to be left in the briefcase to avoid travelling mishaps. :-) Ah, the joys of advancing age. ------------------------------ Date: Fri, 22 Aug 2008 15:41:36 +0200 From: "P. Sture" Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <00A7E75B.E1A3D903@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG > writes: > > FWIW, reading the patch description text (Yes, with my specs on), there > > is nothing to indicate the severity of or need for applying this patch! > > I'd wager that there are sites that will NEVER install this patch unless > > they see some buffer overflow in SMG. Unless this patch is listed as a > > SECURITY patch, people not following what has been going on here for the > > better part of a week will not install it. > > Yes. the rating is INSTAL_1, but it should be a MUP! I second that 100%! -- Paul Sture ------------------------------ Date: Fri, 22 Aug 2008 08:56:23 -0700 (PDT) From: DaveG Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: On Aug 22, 8:41=A0am, "P. Sture" wrote: > In article , > =A0koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > > > In article <00A7E75B.E1A3D...@SendSpamHere.ORG>, =A0 VAXman- =A0@SendSp= amHere.ORG > > writes: > > > FWIW, reading the patch description text (Yes, with my specs on), the= re > > > is nothing to indicate the severity of or need for applying this patc= h! > > > I'd wager that there are sites that will NEVER install this patch unl= ess > > > they see some buffer overflow in SMG. =A0Unless this patch is listed = as a > > > SECURITY patch, people not following what has been going on here for = the > > > better part of a week will not install it. > > > =A0 =A0Yes. =A0the rating is INSTAL_1, but it should be a MUP! > > I second that 100%! > > -- > Paul Sture FWIW, I sent Ann Mc... a comment regarding the MUP Vs Install 1 thingie. ------------------------------ Date: Fri, 22 Aug 2008 08:54:22 GMT From: "Tim Wilkinson" Subject: strange tcpip issue Message-ID: <29vrk.46379$E41.56@text.news.virginmedia.com> OK please be gentle, it must be 15 years since I last touched a vax./vms So VMS 7.3 installed and working on a subnetted network. (tcp on a vax. new to me, it was all decnet and lat in my day). So. my company use the RFC1918 scheme globally the UK has 10.32.0.0/12 assigned to it. When we get to my home I have a wonderfully generous /28 subnet mask applied. so whilst my dhcp router dishes out address with a netmask of 255.255.255.240 which is picked up by my PC/linux boxes etc. I issue the command on my vms system TCPIP> ifconfig -a LO0: flags=100c89 inet 127.0.0.1 netmask ff000000 ipmtu 4096 QE0: flags=c63 inet 10.34.220.88 netmask ff000000 broadcast 10.255.255.255 ipmtu 1500 QE1: flags=c43 inet 192.168.17.125 netmask ffffff00 broadcast 192.168.17.255 ipmtu 1500 TN0: flags=80 so interface QE0 which is assigned using dhcp is picking up the correct ip address, but ignores the subnet mask and assigns the wrong mask of ff000000, and incorrect broadcast address. my pc etc on the same network gives me Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : netgear.com IP Address. . . . . . . . . . . . : 10.34.220.89 Subnet Mask . . . . . . . . . . . : 255.255.255.240 Default Gateway . . . . . . . . . : 10.34.220.81 So I know my router/dhcp configs are right. I had seen similar in old systems years ago, where ip stacks did not properly support subnet masking. But I would have thought DEC would have got this right. Advice please guys how do I fix this ------------------------------ Date: Fri, 22 Aug 2008 10:26:07 +0100 From: "R.A.Omond" Subject: Re: strange tcpip issue Message-ID: <48ae869d$0$90264$14726298@news.sunsite.dk> Tim Wilkinson wrote: > OK please be gentle, it must be 15 years since I last touched a vax./vms Aha, excuses, excuses ... ;-) > So VMS 7.3 installed and working on a subnetted network. (tcp on a vax. new > to me, it was all decnet and lat in my day). > [...snip...] > > I had seen similar in old systems years ago, where ip stacks did not > properly support subnet masking. But I would have thought DEC would have got > this right. Old(er) versions of TCP/IP Services did indeed have this problem. I don't recall off the top of my head which version this eventually got fixed in. Please tell us what version you are using: $ tcpip show version > Advice please guys how do I fix this Simple: install a more recent version where subnetting works. ------------------------------ Date: Fri, 22 Aug 2008 09:44:21 GMT From: "Tim Wilkinson" Subject: Re: strange tcpip issue Message-ID: "R.A.Omond" wrote in message news:48ae869d$0$90264$14726298@news.sunsite.dk... > Tim Wilkinson wrote: > >> OK please be gentle, it must be 15 years since I last touched a vax./vms > > Aha, excuses, excuses ... ;-) > But in my case true >> > Old(er) versions of TCP/IP Services did indeed have this problem. > I don't recall off the top of my head which version this eventually > got fixed in. Please tell us what version you are using: > > $ tcpip show version and as if by magic :- TCPIP> show version Compaq TCP/IP Services for OpenVMS VAX Version V5.1 on a VAXserver 3900 Series running OpenVMS V7.3 > >> Advice please guys how do I fix this > > Simple: install a more recent version where subnetting works. And here lies the rub. I am using simh and a hobbyist install at home. No access to updates etc. Not like when I had multitude of real vaxes and support contracts etc. (go on what is the collective noun for a group of vaxes and don't tell me it is a cluster) It is just my home network for ease is vpned into the company network otherwise I would have stuck with addresses that had their subnets in the recognised class ranges Thanks Tim ------------------------------ Date: Fri, 22 Aug 2008 11:23:47 +0100 From: "R.A.Omond" Subject: Re: strange tcpip issue Message-ID: <48ae941f$0$90262$14726298@news.sunsite.dk> Tim Wilkinson wrote: > ...snip...] >> $ tcpip show version > > and as if by magic :- > > TCPIP> show version > > Compaq TCP/IP Services for OpenVMS VAX Version V5.1 > on a VAXserver 3900 Series running OpenVMS V7.3 Yep, if I recall correctly, version 5.1 didn't subnet properly. >>> Advice please guys how do I fix this >> Simple: install a more recent version where subnetting works. > > And here lies the rub. I am using simh and a hobbyist install at home. No > access to updates etc. Not like when I had multitude of real vaxes and > support contracts etc. (go on what is the collective noun for a group of > vaxes and don't tell me it is a cluster) It is just my home network for ease > is vpned into the company network otherwise I would have stuck with > addresses that had their subnets in the recognised class ranges "No access to updates" ?? Sure you have ... you just need to ask politely here ;-) Do you have access from your home network to the big, bad, outside world ? ------------------------------ Date: Fri, 22 Aug 2008 11:53:24 GMT From: "Tim Wilkinson" Subject: Re: strange tcpip issue Message-ID: > "No access to updates" ?? > > Sure you have ... you just need to ask politely here ;-) > > Do you have access from your home network to the big, bad, > outside world ? Please, pretty please with a sugar coating, is that nice and polite enough? Plenty of outside access. If somebody can point me in the right direction to updates. Thanks for the help. ------------------------------ Date: 22 Aug 2008 12:08:10 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: strange tcpip issue Message-ID: <6h7ohaFjp7tnU1@mid.individual.net> In article , "Tim Wilkinson" writes: >> "No access to updates" ?? >> >> Sure you have ... you just need to ask politely here ;-) >> >> Do you have access from your home network to the big, bad, >> outside world ? > > Please, pretty please with a sugar coating, is that nice and polite enough? > > Plenty of outside access. If somebody can point me in the right direction to > updates. > > Thanks for the help. OK, let me say it before anyone else does!! Go to Process Software and get Multinet under their hobbyist program. You won't regret it and you'll never go back to UCX. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Fri, 22 Aug 2008 14:15:46 +0100 From: "R.A.Omond" Subject: Re: strange tcpip issue Message-ID: <48aebc6f$0$90265$14726298@news.sunsite.dk> Tim Wilkinson wrote: >> "No access to updates" ?? >> >> Sure you have ... you just need to ask politely here ;-) >> >> Do you have access from your home network to the big, bad, >> outside world ? > > Please, pretty please with a sugar coating, is that nice and polite enough? > > Plenty of outside access. If somebody can point me in the right direction to > updates. I'll dig out the appropriate CD some time this afternoon and I'll get back to you off-line. ------------------------------ Date: Fri, 22 Aug 2008 09:22:09 -0400 From: "Richard B. Gilbert" Subject: Re: strange tcpip issue Message-ID: Tim Wilkinson wrote: > OK please be gentle, it must be 15 years since I last touched a vax./vms > > So VMS 7.3 installed and working on a subnetted network. (tcp on a vax. new > to me, it was all decnet and lat in my day). > > > So. my company use the RFC1918 scheme globally the UK has 10.32.0.0/12 > assigned to it. When we get to my home I have a wonderfully generous /28 > subnet mask applied. > > so whilst my dhcp router dishes out address with a netmask of > 255.255.255.240 which is picked up by my PC/linux boxes etc. I issue the > command on my vms system > > > TCPIP> ifconfig -a > LO0: flags=100c89 > inet 127.0.0.1 netmask ff000000 ipmtu 4096 > > QE0: flags=c63 > inet 10.34.220.88 netmask ff000000 broadcast 10.255.255.255 ipmtu 1500 > > QE1: flags=c43 > inet 192.168.17.125 netmask ffffff00 broadcast 192.168.17.255 ipmtu > 1500 > > TN0: flags=80 > > so interface QE0 which is assigned using dhcp is picking up the correct ip > address, but ignores the subnet mask and assigns the wrong mask of > ff000000, and incorrect broadcast address. > > my pc etc on the same network gives me > Ethernet adapter Local Area Connection: > > Connection-specific DNS Suffix . : netgear.com > IP Address. . . . . . . . . . . . : 10.34.220.89 > Subnet Mask . . . . . . . . . . . : 255.255.255.240 > Default Gateway . . . . . . . . . : 10.34.220.81 > So I know my router/dhcp configs are right. > > I had seen similar in old systems years ago, where ip stacks did not > properly support subnet masking. But I would have thought DEC would have got > this right. > > Advice please guys how do I fix this > > Which TCP/IP stack are you using? There is one available from HP which is known as "The Ultrix Connection" or "UCX". There are also a few third party TCP/IP stacks available; "Multinet" from TGV, Inc is one such. FWIW I configured my VMS systems without the benefit of DHCP. My router assigns addresses from "100" up. My HP printer and all the VMS, Solaris, and Linux systems have static addresses (1-99) configured using the tools in SYS$MANAGER:TCPIP*. This allows my PC to KNOW where to find my Alphas, my VAXen (if I ever power them up again) and my Sun Ultra 10 workstations. -- draco vulgaris ------------------------------ End of INFO-VAX 2008.459 ************************