INFO-VAX Sat, 30 Aug 2008 Volume 2008 : Issue 474 Contents: Re: accessing memory by user-mode programs Re: Advanced Server 7.3B & VISTA 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: Hobbyist rx2600 Re: Hobbyist rx2600 Re: NFS setup with TCPIP services, what causes share to not mount? Re: NFS setup with TCPIP services, what causes share to not mount? Re: NFS setup with TCPIP services, what causes share to not mount? Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: Remote access vulnerability in VMS Re: rx2600s on eBay Re: rx2600s on eBay Re: rx2600s on eBay Re: switch vs. hub for hobbyist cluster Re: Used disks on eBay (was Hobbyist rx2600) ---------------------------------------------------------------------- Date: 29 Aug 2008 18:49:00 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: accessing memory by user-mode programs Message-ID: <6hquksFn9qokU1@mid.individual.net> In article , John Sauter writes: > Bill Gunshannon wrote: >> In article , >> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>> In article <6hqa98FngtrnU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>>> What does this have to do with the PDP-11? If the system basicly has >>>> 4Meg of memory, what is to stop me from accessing a block of memory in >>>> I space and writing malicious code there that I later force a branch to? >>>> Ift his is impossible, what is the mechanism of the CPU that would >>>> prevent it? >>> 4MB of RAM is 22 bits of address space. Being a 16 bit system >>> nothing a PDP-11 instruction can do will address outside of a 16 bit >>> address space, only 64KB. The rest of RAM is reached via base >>> address registers which the kernel controls. >>> >>> So if I space and D space are separated by more than 64K, you can't >>> write to I space in user mode. >> >> So, there is no way a user can fudge with the map registers outside of the >> OS using Macro or whatever? I never really looked, in depth, at how the >> map boards on things like my 11/24 and 11/44 worked. I remember seeing >> info in various places explaining how to program it. I was just curious >> if it was possible for a user to do that on a running system. >> >> Can I assume things like the VAX and Alpha are strictly flat address space >> with all memory visible? >> >> bill >> >> > Short of exploiting a bug in the operating system, a user-mode program > cannot access the mapping registers. I don't remember for sure, but I > think they are in the I/O page, which user mode programs cannot access. > This is enforced at the instruction-set level, so it doesn't matter what > language you are coding in. > > The VAX and the Alpha have a strictly flat address space, but it is not > the case that all memory is visible. Any address used by a user-mode > program is first fed to the paging logic, which will fault if the > address is not valid, and translate it through the page table if it is. > Thus, a user-mode program can only access the memory that the operating > system allows it to access. > John Sauter (John_Sauter@systemeyescomputerstore.com) Thank you very much for the explanation. Any day I learn something new it was worth getting out of bed in the morning!! 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, 29 Aug 2008 13:29:01 -0700 (PDT) From: Bobby Subject: Re: Advanced Server 7.3B & VISTA Message-ID: <1cfeffcd-87af-4111-8de2-8e7e130abcdd@m45g2000hsb.googlegroups.com> Well, I finally made progress, just in time to forget about it over the upcoming holiday weekend. It turns out that if the password is typed on the Vista side in "all caps", then connection to AdvancedServer is successful. Entering the password in "small caps" fails with a "logon_not_valid" SMB message. I thought that Advanced Server was case-insensitive? My logon from XP is in all lower case (user & password), and the username for the (successful) Vista login is in lower-case, but not the password. It is my understanding that LMNT authentication converts the password to UpperCase during the encryption process, but that apparently isn't happening on my test machine. Now I'm wondering if there's a setting somewhere on either the VMS or Vista side for this, or if it is a bug? ------------------------------ Date: 29 Aug 2008 18:53:36 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6hqutgFn9qokU2@mid.individual.net> In article , Rob Brown writes: > On Fri, 29 Aug 2008, Bill Gunshannon wrote: > >> What does this have to do with the PDP-11? If the system basicly >> has 4Meg of memory, what is to stop me from accessing a block of >> memory in I space and writing malicious code there that I later >> force a branch to? Ift his is impossible, what is the mechanism of >> the CPU that would prevent it? > > You could use the RSX Program Logical Address Space (PLAS) directives > to do this. Take some D-space memory, which could be allocated as > .BLKW directives in your source code, or could be allocated from > unused memory by a PLAS directive. If the latter, you could specify > that it either disappear, or continue to exist after your task exits. > > Write your code into this D-space. > > Use a PLAS directive to create an I-space address window and map it to > the memory you had previously written the code to, and then branch to > it. > > Of course you could also just create a resident library ala LINK/SHARE > in VMS. > > How malicious can it be? I think it is about the same as any other > Trojan. Trick somebody with privileges into executing your code. > Your code will execute with the privileges of the task/user that > branches to it. > > Now that I have written all this, I reread your original question see > you asked: > >> ... accessing a block of memory in I space ... > > Perhaps there is some misunderstanding here. > > Of the 4 Megabytes in a PDP-11, none of if is either I-space or > D-space until it is mapped. The memory management hardware on a > PDP-11 maps memory in 8KB pages, using 8 I-space Address Page > Registers (APRs) and 8 D-space APRs. There are separate sets of APRs > for kernel mode, supervisor mode, and user mode. When a user task > runs, the user mode APRs are set up to point to the tasks physical > memory. The task may modify its APRs using PLAS directives as allowed > by the executive. So it is possible to map the same physical memory > in both I-space and D-space simultaneously. > > Am I making sense? Yes, I appreciate the lesson. And all the info from everybody else who answered my request. Trust me, I learn a lot more here than I ever did in a classroom. And I am still learning..... Thanks to all. 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: 29 Aug 2008 18:57:00 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6hqv3sFn9qokU3@mid.individual.net> In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5ab10@l42g2000hsc.googlegroups.com>, DaveG writes: > While this trip down editor and I&D memory lane is interesting, and > maybe I missed something, but what do these subjects have to do with > the (almost) recent OpenVMS security findings? > > OK I'll duck now. Here come the slings and arrows. Probably nothing other than the recent exploits have made me wonder just how lucky we were in the days when people had the moral fiber to not do the kinds of things we find ourselves fighting today. All I had to worry about in my Univac-1100 days was a program crshing because of a wayward write to I-Space. Today someone would be looking for ways to do it deliberately and in a controlable fashion for vefarious purposes. A sad statement about our industry and society in general. 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, 29 Aug 2008 19:19:47 GMT From: Roger Ivie Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On 2008-08-29, Bob Koehler wrote: > VAX and Alpha have flat 32 bit or 64 bit virtual address spaces > mapped to flat same size or smaller RAM addresses. More recent VAX models can handle up to (IIRC) 35 physical address bits. They took over the "reserved for software use" bits in the PTE and used them to extend the page-frame number. -- roger ivie rivie@ridgenet.net ------------------------------ Date: 29 Aug 2008 19:28:30 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6hr0uuFn6gc4U1@mid.individual.net> In article , "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5ab10@l42g2000hsc.googlegroups.com>, >> DaveG writes: >>> While this trip down editor and I&D memory lane is interesting, and >>> maybe I missed something, but what do these subjects have to do with >>> the (almost) recent OpenVMS security findings? >>> >>> OK I'll duck now. Here come the slings and arrows. >> >> Probably nothing other than the recent exploits have made me wonder >> just how lucky we were in the days when people had the moral fiber >> to not do the kinds of things we find ourselves fighting today. All >> I had to worry about in my Univac-1100 days was a program crshing >> because of a wayward write to I-Space. Today someone would be looking >> for ways to do it deliberately and in a controlable fashion for >> vefarious purposes. A sad statement about our industry and society >> in general. >> > > Well, the rot set in a LONG time ago. Twenty-four years ago, I had > graduate students using my systems at Princeton University. Somebody > invented (re-invented?) login spoofing to steal passwords. They would > put up a login prompt and wait for some sucker to come along and type > his user name. Then their program prompted for password and followed > that with a "login failure" message. The user would try again and THIS > time would get a real login prompt. I pointed this out agesa go in one of the discussionas about wether or not VMS was ever subject to "Trojans", this being the classic Trojan attack. It was done here on VMS all the time when we had labs of VT100's connected to DECServers. And, just for fun I used the exact same ploy in a "demonstration of concept" in my Network Class down at Ft. Gordon this past summer. Only I did it with the web and a faked Google Gmail login screen. Amazing how a class full of IT professionals had never seen this done and had no idea it could be done as quickly and easily as I did it. > > I looked out my office window one day and saw a TV camera focused on my > keyboard. I called the director of the lab who came to my office, > examined the evidence and then cut a bloody swath through the grad students. You would be amazed how many classroom combinations I was able to collect as people stood right there in front of all the students keying them in. Sometimes technology is still the hard way and good ole social engineering is still the best way. 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: 29 Aug 2008 20:01:33 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <6hr2ssFn6pkrU1@mid.individual.net> In article , "Richard B. Gilbert" writes: > Bill Gunshannon wrote: >> In article , >> "Richard B. Gilbert" writes: >>> Bill Gunshannon wrote: >>>> In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5ab10@l42g2000hsc.googlegroups.com>, >>>> DaveG writes: >>>>> While this trip down editor and I&D memory lane is interesting, and >>>>> maybe I missed something, but what do these subjects have to do with >>>>> the (almost) recent OpenVMS security findings? >>>>> >>>>> OK I'll duck now. Here come the slings and arrows. >>>> Probably nothing other than the recent exploits have made me wonder >>>> just how lucky we were in the days when people had the moral fiber >>>> to not do the kinds of things we find ourselves fighting today. All >>>> I had to worry about in my Univac-1100 days was a program crshing >>>> because of a wayward write to I-Space. Today someone would be looking >>>> for ways to do it deliberately and in a controlable fashion for >>>> vefarious purposes. A sad statement about our industry and society >>>> in general. >>>> >>> Well, the rot set in a LONG time ago. Twenty-four years ago, I had >>> graduate students using my systems at Princeton University. Somebody >>> invented (re-invented?) login spoofing to steal passwords. They would >>> put up a login prompt and wait for some sucker to come along and type >>> his user name. Then their program prompted for password and followed >>> that with a "login failure" message. The user would try again and THIS >>> time would get a real login prompt. >> >> I pointed this out agesa go in one of the discussionas about wether or not >> VMS was ever subject to "Trojans", this being the classic Trojan attack. >> It was done here on VMS all the time when we had labs of VT100's connected >> to DECServers. >> >> And, just for fun I used the exact same ploy in a "demonstration of concept" >> in my Network Class down at Ft. Gordon this past summer. Only I did it >> with the web and a faked Google Gmail login screen. Amazing how a class >> full of IT professionals had never seen this done and had no idea it could >> be done as quickly and easily as I did it. >> >>> I looked out my office window one day and saw a TV camera focused on my >>> keyboard. I called the director of the lab who came to my office, >>> examined the evidence and then cut a bloody swath through the grad students. >> >> You would be amazed how many classroom combinations I was able to collect >> as people stood right there in front of all the students keying them in. >> Sometimes technology is still the hard way and good ole social engineering >> is still the best way. >> >> bill >> >> > > This trick doesn't work on VMS if you are careful to hit the return key > before trying to log in! Yeah, that's what people here have always said. Too bad the average user (in my case, student, faculty and most staff) didn't know that. > > I've sat in the airport and watched crew unlock the five button > combination lock to the boarding thingummy! I was able to recover the > combination although I didn't see any way to make use of it! In that case, not sure what you get. In my case it meant seldom having to stand around int he hall waiting for some civilian to show up and open the classroom for me. I tend to start my day about an hour and half before most contractors. :-) 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, 29 Aug 2008 16:41:16 -0400 From: JF Mezei Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <48b85f07$0$9629$c3e8da3@news.astraweb.com> re: memory protection. Can anyone explain to me why I was under the impression that under VMS, you could not branch to data because data blocks were marked no-execute (or whatever) ? Was this ever the case ? This argument had been brought up, (perhaps in my dreams) to show how VMS was far mroe immune to buffer overflows than other operating systems. (with the corrolary that you could not write to execute sections and overwrite code). Recent discussions seem to have completely shattered these misconceptions I had, but i am really puzzled as to why I would have had them to begin with. ------------------------------ Date: 29 Aug 2008 15:44:43 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5ab10@l42g2000hsc.googlegroups.com>, DaveG writes: > While this trip down editor and I&D memory lane is interesting, and > maybe I missed something, but what do these subjects have to do with > the (almost) recent OpenVMS security findings? The I & D concept could potentially block the buffer overrun which at least one of those findings seems to have exploited. ------------------------------ Date: 29 Aug 2008 15:54:24 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <1Kj8oWUazEvm@eisner.encompasserve.org> In article , Roger Ivie writes: > On 2008-08-29, Bob Koehler wrote: >> VAX and Alpha have flat 32 bit or 64 bit virtual address spaces >> mapped to flat same size or smaller RAM addresses. > > More recent VAX models can handle up to (IIRC) 35 physical address bits. > They took over the "reserved for software use" bits in the PTE and used > them to extend the page-frame number. OK. I recall when they extended the 30 bit hardware design of the 11/780's SBI to a 32 bit design, but I didn't know they went beyond that. What does the VAX do with those other 3 bits? Segmentation, APRs, or something else? ------------------------------ Date: Fri, 29 Aug 2008 14:17:46 -0700 (PDT) From: DaveG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <4e808ea4-f34a-459b-b582-16bbfb71b299@m36g2000hse.googlegroups.com> On Aug 29, 3:44=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <52d8b2bd-0f07-4a2c-b30d-eaaca4f5a...@l42g2000hsc.googlegroups= .com>, DaveG writes: > > > While this trip down editor and I&D memory lane is interesting, and > > maybe I missed something, but what do these subjects have to do with > > the (almost) recent OpenVMS security findings? > > =A0 =A0The I & D concept could potentially block the buffer overrun which > =A0 =A0at least one of those findings seems to have exploited. OK thanks for that. But editor wars? ;-) ------------------------------ Date: Fri, 29 Aug 2008 14:38:10 -0700 (PDT) From: Rich Jordan Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <5259175f-ffba-4423-ac31-be6c81f98b73@r66g2000hsg.googlegroups.com> On Aug 29, 3:54=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , Roger Ivie writes: > > On 2008-08-29, Bob Koehler wr= ote: > >> =A0 =A0VAX and Alpha have flat 32 bit or 64 bit virtual address spaces > >> =A0 =A0mapped to flat same size or smaller RAM addresses. =A0 > > > More recent VAX models can handle up to (IIRC) 35 physical address bits= . > > They took over the "reserved for software use" bits in the PTE and used > > them to extend the page-frame number. > > =A0 =A0OK. =A0I recall when they extended the 30 bit hardware design of t= he > =A0 =A011/780's SBI to a 32 bit design, but I didn't know they went > =A0 =A0beyond that. > > =A0 =A0What does the VAX do with those other 3 bits? =A0Segmentation, APR= s, > =A0 =A0or something else? Late VAXen could go to 3.5GB physical memory. The page at http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_042.html provides a little info about the "XVA" and "XPA" (extended virtual/ physical addressing); all bigger VAXen so I never actually saw or worked on one... Rich ------------------------------ Date: Fri, 29 Aug 2008 18:50:58 -0500 From: BRAD@rabbit.turquoisewitch.com (Brad Hamilton) Subject: Re: Hobbyist rx2600 Message-ID: In article <47ebb880-034f-4911-a9ad-d74943327ff3@a70g2000hsh.googlegroups.com>, sampsal@gmail.com wrote: [...] >Anybody have any experience buying hard drives from ebay? Something >tells me it might be a Bad Idea (even with the potential upside of >getting some UK gov ministry's data for 50 million people as an added >bonus)? I bought a few Alphas with drives and haven't had any fail, >I'm guessing the SCSI drives that come with this grade of system are a >bit more high grade than your run-of-the-mill IDE / SATA disks, so am >considering it as an option. I have bought *many* SCSI HD from eBay for my Alpha, to stick in existing SBB blue bricks. Only one outright failure in all that time, which set me back about USD$10.00 (and I was able to re-use the SBB brick, so not a total loss). I've had good luck with user partssalesbay, although the site is US, and you seem to be located across the pond. ------------------------------ Date: Fri, 29 Aug 2008 17:26:58 -0700 (PDT) From: FrankS Subject: Re: Hobbyist rx2600 Message-ID: On Aug 29, 7:50=A0pm, B...@rabbit.turquoisewitch.com (Brad Hamilton) wrote: > I have bought *many* SCSI HD from eBay for my Alpha, to stick in existing= SBB > blue bricks. =A0Only one outright failure in all that time, which set me = back > about USD$10.00 (and I was able to re-use the SBB brick, so not a total l= oss). > Same here, and for the same purpose. I've bought RZ1CD (4.5gb in a blue SBB) drives as cheaply as possible just so that I can remove the 4.5gb and put in, say, a 146gb drive. I've had mixed results buying bare SCSI disks (to install into said blue SBB) on eBay. For the most part they've worked out fine. Occassionally I get a drive that fails within months. I only buy drives that are claimed to be new, though I'm sure the experiences with used drives wouldn't be much different. ------------------------------ Date: Fri, 29 Aug 2008 12:56:04 -0700 (PDT) From: Rich Jordan Subject: Re: NFS setup with TCPIP services, what causes share to not mount? Message-ID: On Aug 29, 9:54=A0am, Rich Jordan wrote: > On Aug 28, 9:06=A0pm, JF Mezei wrote: > > > > > Rich Jordan wrote: > > > /ds1/user/dave =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > > > /ds3/files/ups =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 * > > > Any thoughts? =A0 > > > Start by enabling read-write for world on ds1:[000000]000000.dir as wel= l > > as ds1:[000000]user.dir > > > See if it makes a difference. (then set it back to what it was before). > > > Also, make sure that the protection of the mount point file on the > > client system is setup properly. > > > If I remember correctly, the NFS server on VMS doesn't honour ACLs. =A0= Not > > 100% sure of it though. > > > I was told that file protections are often the cause of NFS headaches, > > and it was by fixing them that I got my setup between a mac and VMS wor= king. > > No go. =A0Tried various settings all the way up to G:RWED W:RWED, but > the nfs server continues to fail to map the export, with the same > error in the log. > > Also tried redoing the map and the export in uppercase, matching the > actual directory names. > > Also tried mapping several other shared directories on DSA1, using > both all lowercase and 'exactly as shown' for export, with protections > back up to the root directory of W:RWE, no go, same error. > > So nothing I've tried is able to get anything on drive DSA1 to map or > generate a more useful error. > > Rich Tried other variants of the drive map in case it didn't like /ds1 or / DS1. Also tried aiming at a logical instead of the device name, with variation on the logical definition. Nothing works. Blew away the NFS config completely and rebuilt. Created test directories on DSA1 and DSA3. Any directory on DSA3 exports fine, even with the path leading to it protected. Any directory on DSA1 cannot be shared with the same error, regardless of the UIC protections leading up the path. I'm stumped. I will be turning on access auditing on the directories making up the export path and see if there's any way to increase the NFS logging level (not documented in the manual, but maybe elsewhere). If anyone has a suggestion on correcting, or at least narrowing down the reason for this behavior I'd love to hear it. Thanks and have a great weekend. Rich ------------------------------ Date: Fri, 29 Aug 2008 13:58:03 -0700 (PDT) From: Rich Jordan Subject: Re: NFS setup with TCPIP services, what causes share to not mount? Message-ID: <22de5ea7-8044-45d8-9f41-8d9af2ba4528@26g2000hsk.googlegroups.com> On Aug 29, 2:56=A0pm, Rich Jordan wrote: > On Aug 29, 9:54=A0am, Rich Jordan wrote: > > > > > On Aug 28, 9:06=A0pm, JF Mezei wrote: > > > > Rich Jordan wrote: > > > > /ds1/user/dave =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = * > > > > /ds3/files/ups =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 * > > > > Any thoughts? =A0 > > > > Start by enabling read-write for world on ds1:[000000]000000.dir as w= ell > > > as ds1:[000000]user.dir > > > > See if it makes a difference. (then set it back to what it was before= ). > > > > Also, make sure that the protection of the mount point file on the > > > client system is setup properly. > > > > If I remember correctly, the NFS server on VMS doesn't honour ACLs. = =A0Not > > > 100% sure of it though. > > > > I was told that file protections are often the cause of NFS headaches= , > > > and it was by fixing them that I got my setup between a mac and VMS w= orking. > > > No go. =A0Tried various settings all the way up to G:RWED W:RWED, but > > the nfs server continues to fail to map the export, with the same > > error in the log. > > > Also tried redoing the map and the export in uppercase, matching the > > actual directory names. > > > Also tried mapping several other shared directories on DSA1, using > > both all lowercase and 'exactly as shown' for export, with protections > > back up to the root directory of W:RWE, no go, same error. > > > So nothing I've tried is able to get anything on drive DSA1 to map or > > generate a more useful error. > > > Rich > > Tried other variants of the drive map in case it didn't like /ds1 or / > DS1. =A0Also tried aiming at a logical instead of the device name, with > variation on the logical definition. =A0Nothing works. > > Blew away the NFS config completely and rebuilt. =A0Created test > directories on DSA1 and DSA3. =A0Any directory on DSA3 exports fine, > even with the path leading to it protected. =A0Any directory on DSA1 > cannot be shared with the same error, regardless of the UIC > protections leading up the path. > > I'm stumped. =A0I will be turning on access auditing on the directories > making up the export path and see if there's any way to increase the > NFS logging level (not documented in the manual, but maybe elsewhere). > > If anyone has a suggestion on correcting, or at least narrowing down > the reason for this behavior I'd love to hear it. > > Thanks and have a great weekend. > > Rich Now I will have a great weekend too. When you export a share on a mapped ODS5 volume you apparently have to specify the /OPT=3DNAME_CONVERSION on the ADD EXPORT command line. This is in contradiction to the info in the TCPIP management guide which states: "If and ODS-5 volume is mapped and exported, the NFS server automatically supports EFS features and ignores the NAME_CONVERSION option of the EXPORT command, if it is specified in the export record" I'll send a note to the docs people. Rich ------------------------------ Date: Fri, 29 Aug 2008 17:01:31 -0400 From: JF Mezei Subject: Re: NFS setup with TCPIP services, what causes share to not mount? Message-ID: <48b863d3$0$12398$c3e8da3@news.astraweb.com> Rich Jordan wrote: > Tried other variants of the drive map in case it didn't like /ds1 or / > DS1. Also tried aiming at a logical instead of the device name, with > variation on the logical definition. Nothing works. Here is some of the exports I have: /disk2/users/jfmezei BRAKES, 10.0.0.20 Options: Purge Typeless Name_cvt /disk2/www_main 10.0.0.20, BRAKES Options: Purge Typeless /disk2/www_wap 10.0.0.20, BRAKES Options: Purge Typeless Name_cvt This is on an ODS5 disk. I guess I should also have the Name_conversion in the www_main options. help add export gives you the list of options. NFS doesn't give out much in terms of debugging, yet it is picky to the extreme. And this isn't just for VMS. I guess I could be using wireshark to see if it can parse NFS packets and give me more info on how it works. Also, remember WHO mounts the drive on the client side. On a mac, if the drive is mounted by automount, then "root" is the one that mounts, and you then have to make sure the protection of the file that is the mount point on the client works correctly for the actual user. ------------------------------ Date: Fri, 29 Aug 2008 16:36:14 -0400 From: JF Mezei Subject: Re: Remote access vulnerability in VMS Message-ID: <48b85dd9$0$9629$c3e8da3@news.astraweb.com> Simon Clubley wrote: > Hoff is reporting at > > http://64.223.189.234/node/1021 > > that a remote access exploit against VMS has been discovered and verified. Woopty doo ! Since his announcement is devoid of *ANY* information, it is absolutely meaningless. Sorry Hoff but it has to be said. So far, I have found many vulnerabilities over the years, including XDM, POP and IMAP, but they have yet to be fixed. ------------------------------ Date: Sat, 30 Aug 2008 10:05:37 +0800 From: "Richard Maher" Subject: Re: Remote access vulnerability in VMS Message-ID: Hi JF, > Woopty doo ! Since his announcement is devoid of *ANY* information, it It could be very informative. Not wanting to have a(nother :-) go at Hoff personally, but if the company reporting the problem is also one of his customers and he heard about it through his association with them, then that's peachy. OTOH, if he was fed this valuable information through his continued links with VMS' Cosa Vostre, and is now able to evaluate the potential risks to his (and his customer(s)') servers and take remedial action, while simple license-paying fodder are left vulnerable floundering in the dark, then I think that'd be indictable. I hope I'm wrong, but there was another recent post here indicating that some were fortunate enough to enjoy the patronage of the Andy Goldsteins of this world, and were getting direct updates on the availability of patches for other vulnerabilities while, presumably, fee-generating customers like NasdaqOMX are told to piss-off and just wait in line like everybody else? So how do you get in with this in-crowd? Who do you have to sleep with (or threaten to sleep with :-) Is there a Clique-Membership upgrade-option on the license/warranty agreement that one can tick? A school-tie? A secret-handshake? A political/sexual/religious orientation that always helps? Just whose arse(s) do you have to kiss? Heaven-forbid that VMS would be run on a professional and transparent basis ". . .and justice for *all*". Regards Richard Maher "JF Mezei" wrote in message news:48b85dd9$0$9629$c3e8da3@news.astraweb.com... > Simon Clubley wrote: > > Hoff is reporting at > > > > http://64.223.189.234/node/1021 > > > > that a remote access exploit against VMS has been discovered and verified. > > > Woopty doo ! Since his announcement is devoid of *ANY* information, it > is absolutely meaningless. Sorry Hoff but it has to be said. > > So far, I have found many vulnerabilities over the years, including XDM, > POP and IMAP, but they have yet to be fixed. ------------------------------ Date: Fri, 29 Aug 2008 21:38:05 -0500 From: BRAD@rabbit.turquoisewitch.com (Brad Hamilton) Subject: Re: Remote access vulnerability in VMS Message-ID: In article , Richard Maher wrote: >Hi JF, > >> Woopty doo ! Since his announcement is devoid of *ANY* information, it > >It could be very informative. Not wanting to have a(nother :-) go at Hoff [...] You know, the SMGSHR MUP came out in a pretty timely fashion, all things considered - thanks (probably) in large part to the visibility provided by this NG, as well as the efforts by the folks from DEFCON 16 who made us aware of the issue in the first place. It's nice to know that the mechanism "worked", and that complain.on.vms turned out to be a somewhat-valuable resource to the community. :-) Please continue posting - your screeds are highly entertaining, and could be more so with a little less acidity. :-) ------------------------------ Date: Fri, 29 Aug 2008 19:49:57 -0700 From: Malcolm Dunnett Subject: Re: Remote access vulnerability in VMS Message-ID: Richard Maher wrote: > Hi JF, > >> Woopty doo ! Since his announcement is devoid of *ANY* information, it > > It could be very informative. Not wanting to have a(nother :-) go at Hoff > personally, but if the company reporting the problem is also one of his > customers and he heard about it through his association with them, then > that's peachy. OTOH, if he was fed this valuable information through his > continued links with VMS' Cosa Vostre, and is now able to evaluate the > potential risks to his (and his customer(s)') servers and take remedial > action, while simple license-paying fodder are left vulnerable floundering > in the dark, then I think that'd be indictable. > Let's cut Hoff some slack here. It's classic Digital culture to not speak of an exploit (at least not until the fix is widely available). I'm of mixed feelings on this - I'd like to know more so that I could assess if I'm vulnerable (eg it may be that the exploit requires some layered product I'm not using). On the other hand the recent SMG buffer overflow exploit discussion went way too far the other way. If our students still had VMS accounts I'm sure any of the half-clever ones could have gleaned enough information from c.o.v to weaponize the exploit. I just hope a MUP is released soon to correct whatever the problem is. ------------------------------ Date: Sat, 30 Aug 2008 00:46:51 -0400 From: JF Mezei Subject: Re: Remote access vulnerability in VMS Message-ID: <48b8d0e5$0$12400$c3e8da3@news.astraweb.com> Malcolm Dunnett wrote: > Let's cut Hoff some slack here. It's classic Digital culture to not > speak of an exploit (at least not until the fix is widely available). What is the point of announcing a vulnerability without giving *ANY* details ? Might as well have just kept quiet and let HP issue a patch in its onw due time (or have a fix in the next release of VMS). If you're going to keep details away, you would be better off to wait for the patch to be issued and then make a public announcement (HP sure won't) about availability of that patch that fixes a vulnerability. But if you want the patch to come out fast, you then provide enough details to the public to force HP to escalate the issue and assign resources ASAP to fix them. ------------------------------ Date: Fri, 29 Aug 2008 13:04:47 -0700 (PDT) From: jferraro Subject: Re: rx2600s on eBay Message-ID: On Aug 28, 10:27=A0am, Malcolm Dunnett wrote: > FrankS wrote: > > a fair deal. =A0Others will now get an even better deal (IMHO). =A0It's > > less than the price of some zx6000 workstation that have sold on eBay, > > and the rx2600 is on the supported list of servers for OpenVMS > > (whereas the zx6000 is not). > > In defense of the zx6000 it's basically an rx2600 without the management > processor and it runs VMS just fine even if not officially supported. > > Having the management processor is nice though as it gives you a remote > console (via telnet) capability. Interesting... I have a zx6k with an MP... perhaps the Madisons do not?!?!? Joe ------------------------------ Date: Fri, 29 Aug 2008 15:19:37 -0700 From: Malcolm Dunnett Subject: Re: rx2600s on eBay Message-ID: jferraro wrote: >> Having the management processor is nice though as it gives you a remote >> console (via telnet) capability. > > Interesting... I have a zx6k with an MP... perhaps the Madisons do > not?!?!? > I believe it was an option on the zx6000 and standard on the rx2600. I have several zx6000s and none of them came with an MP, however if I install one in them it works just fine. ------------------------------ Date: Fri, 29 Aug 2008 17:16:53 -0700 (PDT) From: FrankS Subject: Re: rx2600s on eBay Message-ID: On Aug 29, 11:58=A0am, cornel...@eisner.decus.org (George Cornelius) wrote: > Will an RRD45 work? =A0I realize I might need a SCSI card if there's > not on-board SCSI. I don't know if an RRD45 will work. The rx2600 does have on-board SCSI, with an external LVD/SE connector. I suppose with appropriate adapters you could get an RRD45 connected. Whether the EFI will allow you to boot from it is an exercise for the reader. There are a few options for the front-mounted CD/DVD drive. Not terribly expensive (on eBay, that is). ------------------------------ Date: Fri, 29 Aug 2008 16:48:45 -0400 From: JF Mezei Subject: Re: switch vs. hub for hobbyist cluster Message-ID: <48b860d5$0$4543$c3e8da3@news.astraweb.com> You're not going to see magical improvements to your network by going to a swicth. But logically, you will have improvements. For one thing, if you have 2 machines capable of 100, then they will finally eb able to talk to each other at normal speed and not let the slower vax slow them down. On the other hand, a switch is a "store and forward" device which introduces some latency, especially at 10mbps. (swicth receives packet fully, then moves it to each of the designated destination port queues where the packets are sent out. So to send 1500 bytes, it will take twice the transmission time (time for switch to receive packet, and time to send it). On a hub, the signals are being duplicvated, so the ports receive the bits at the same time as they are being sent. One big improovement a switch provides is ability to have some nodes at full duplex even those older nodes are not. So your alpha1 could be receiving data from alpha2 while it is sending data to vax1. And it doesn't have to worry about vax1 being busy because the swicth wuill accept the packet and deliver it to vax1 whenever vax1 is ready to listen (since vax are half duplex). ------------------------------ Date: Fri, 29 Aug 2008 19:39:48 -0700 From: Malcolm Dunnett Subject: Re: Used disks on eBay (was Hobbyist rx2600) Message-ID: FrankS wrote: > I've had mixed results buying bare SCSI disks (to install into said > blue SBB) on eBay. For the most part they've worked out fine. > Occassionally I get a drive that fails within months. I only buy > drives that are claimed to be new, though I'm sure the experiences > with used drives wouldn't be much different. I've had very good luck with used DEC/Compaq/HP drives - I've had very few fail and they're cheap enough that I can afford to keep a good stack of spares on a shelf for the few that do fail. With everything RAIDed and HBVSed a disk failure is just a minor annoyance. I've gotten rid of all my blue SBB stuff and mostly use the next generation storageworks carriers and racks (the ones I believe they inherited from Compaq). I generally buy the disks in the carriers (more convenient and not much price difference) I've had somewhat less luck with bare bones "refurbished" white label drives - I think they are actually factory seconds or something, they seem to fail more frequently. I don't buy them anymore. ------------------------------ End of INFO-VAX 2008.474 ************************