INFO-VAX Thu, 21 Aug 2008 Volume 2008 : Issue 456 Contents: Re: Another BIND vulnerability (cache poisoning) Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: Disk remains in HostUnavailable for a very long time Re: DS10L power supply mystery Re: DS10L power supply mystery Re: DS10L power supply mystery Re: lib$find_file on Pascal Looking for a new home 2x MicroVAX 3100/10 LTO3/LTO4 support from OpenVMS 7.2 / ALPHA SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site Re: SMGRTL patch available on ITRC ftp site ---------------------------------------------------------------------- Date: Wed, 20 Aug 2008 16:59:39 -0600 From: Mark Berryman Subject: Re: Another BIND vulnerability (cache poisoning) Message-ID: <48ac3f6d@mvb.saic.com> I hardly ever read this forum any more so please forgive my answer for being 3 weeks after your posting. But, Spud Demon wrote: > david20@alpha2.mdx.ac.uk writes in article dated Fri, 1 Aug 2008 14:58:54 +0000 (UTC): >> In article , "Tom Linden" writes: >>> On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon >>> wrote: >>>> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP). >>> What don't you like about WASD or MX? >>> >> Or PMDF >> >> or even Communigate PRO > > It's not a problem with each and every particular piece of software; it's > that I want to be able to maintain my hobbyist site using a single hardware > platform. My big deal is audio, and in order to keep it on my Alphas, I'm > sticking to version 7.3-1, which means TCPIP 5.4. I do all kinds of audio on my Alpha, using VMS V8.3. I also strongly recommend staying as far away as possible from TCPIP Services. Get a hobbyist copy of Multinet. You will be much happier. > My first migration to Linux was NFS, because the Alpha hardware I own > supports IDE poorly to not-at-all, and also because it's (near?) impossible to > get VMS to talk to MacOS. The Mac NFS client wants to used non-privileged > ports, and VMS insists they be privileged. Linux can be configured to allow > both. A limitation of your chosen IP stack. Either switch to Multinet or add -P to your MacOS NFS mount command to tell it to use a privileged port. All of my Macs NFS mount shares served by my VMS V8.3 system (using Multinet V5.2) and I have had no issues so far. > > SSH is also a big deal to me. UCX has a nasty old version which crashes a > lot. On Linux, it just works. No more worries about whether somebody's > capturing passwords from my telnet sessions, unless I have to manage the VMS > boxes remotely. Get Multinet. The SSH that comes with TCPIP services, especially older versions, is a joke. > No problem with VMS Apache (CSWS) on my current pages, but what if I decide > to write some Java servlets? VMS Java is perpetually behind, and my newer > Linux hardware has more CPU cycles and available memory. VMS has a very recent copy of Java V5. I don't know what you'd want to do in a servlet that might require V6 but I've had too many instances of long working code breaking in V6 that I wouldn't want to use it anyway. > UCX IMAP is incredibly slow. I'm hoping for a 100x speed improvement when I > migrate. The best IMAP server for VMS comes with PMDF. Add Precise Mail Anti-Spam and you've got the best mail server you can put together, especially for a hobbyist. No Linux system comes close (and I've tried most of what's out there). Both are available for hobbyists. Mark Berryman ------------------------------ Date: Wed, 20 Aug 2008 13:09:48 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <1a23462b-f714-4308-b37f-c8700e5f4291@34g2000hsh.googlegroups.com> "On every system I'm familiar with library addresses changes between releases / library versions." Name one good technical reason why library addresses (as seen by user programs or even by other bits of OS code) need to change. I'll give you the reason(s) they change: Laziness, and/or poor design. If VMS can implement "transfer vectors" and similar concepts, which effortlessly protect code from changes in the underlying libraries, so can other OSes, should they wish to do so. I know, I've done it (over twenty years ago). Once upon a time, say in the early VAX era, it could perhaps have been argued that the "overhead" in the transfer vector concept (extra memory usage, extra instructions in common paths, etc) wasn't worth the benefits (e.g. the possibility of effortless binary compatibility going back as far as you want). Don't think that's been a valid concern for the last couple of decades though. Billco didn't worry about this compatibility thing, because they don't give a tinker's cuss about "upward compatibility" and "investment protection" (that kind of thing is complete anathema to the Billco business model, as the latest Vista and Office challenges show only too clearly). Instead, to try and band-aid the inevitable resulting DLL hell for those awkward folks who happen to have important applications that hang around for more than one Windows upgrade cycle, Billco give us "manifests" and "side by side". Argggggggggghhhhhhhhhhhhhhh. Effortless? No, just brainless, and nearly useless. (I don't know whether mainframes worried or whether *n*xes cared). ------------------------------ Date: Wed, 20 Aug 2008 21:23:08 GMT From: Malcolm Dunnett Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <0X%qk.8873$%b7.8649@edtnps82> VAXman- @SendSpamHere.ORG wrote: > In article , JONESD@ecr6.ohio-state.edu (David Jones) writes: >> In message <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com> >> bugs@signedness.org writes: >> >>> On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: >>>> The code for this is 90(16), 144(10) bytes! I adhered to the calling >>>> standard. There are some null quadwords in there (3) to maintain the >>>> proper alignment too. It does NOT take much code to implement this. >>>> Also, I was able to do this "silently", unlike those original demos. >>>> This could be _easily_ weaponized. >> My PoC for zapping AUTHPRIV is 172 bytes (116 code, 52 data+linkage), you >> win. > > :) > > The idea was to keep it small as the *supported* mechanism I used allows > for 252 bytes to be loaded! LIB$PUT_COMMON ? ------------------------------ Date: 20 Aug 2008 21:25:50 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: In message , John Sauter writes: >It could have been, but it wasn't. Even in 1978, there was no doubt >that the overhead of a transfer vector was a worthwhile tradeoff for the >increased compatibility. I loved bit-twiddling on the VAX, the instruction set was so easy to work with. IIRC, the earliest VMS versions had the system service transfer vector in S0 space, but at some point they moved it to P1 space. Since P1 uses the process page table, a non-privileged process could make a copy of the vector, re-map the pages privately as user-mode writable and the restore contents. You could then do some pretty interesting things. Nowadays, you do that more formally with SSISHR. 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: Wed, 20 Aug 2008 16:05:31 -0700 (PDT) From: Neil Rieck Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On Aug 7, 2:15=A0pm, Mark Daniel wrote: > samp...@gmail.com wrote: > > There's apparently an overflow flat in Multinet's Fingerd as well: > > >http://seclists.org/bugtraq/2008/Aug/0056.html > > This appears to behave as described on at least VAX VMS V7.3 MultiNet > V5.1 Rev A-X but not on Alpha VMS V8.3 V5.2 Rev A-X or I64 VMS V8.3 V5.2 > Rev A-X (three platforms I have access to). > > $ echo `perl -e 'print "a"x1000'` | nc -v host.name 79 > Connection to host.name 79 port [tcp/finger] succeeded! > > I guess we can assume the 'group of lads' would be keeping an occasional > eye on c.o.v. :-) > I'm not sure if this is relavent, but I recently read something about buffer overflow exploits in a book from "No Starch Press" titled "hacking" (click http://www.nostarch.com/hacking2.htm ). Basically this is caused by bad C/C++ programming where a string is passed into a C/C++ function as an input parameter, then the called function copies the passed string into a statically allocated local buffer (to prepare for a system call) without first checking the length of the passed string. If the hacker is carefull and knows the actual limit, he will next pass the maxium string size plus some additional characters which will be interpreted as an execution address to be run when the function exits. Is this a problem on OpenVMS with all the cool built-in memory management? I'm not sure. But I do know that many TCP/IP daemons run with more privs than many users, and that any code serving the lowest 255 ports are especially vulnerable. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html http://www3.sympatico.ca/n.rieck/links/openvms_demos.html ------------------------------ Date: Wed, 20 Aug 2008 23:23:59 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <00A7E682.C2D953F9@SendSpamHere.ORG> In article <0X%qk.8873$%b7.8649@edtnps82>, Malcolm Dunnett writes: >VAXman- @SendSpamHere.ORG wrote: >> In article , JONESD@ecr6.ohio-state.edu (David Jones) writes: >>> In message <72983ab7-2712-43cf-a3c9-2b71a79c6be7@f36g2000hsa.googlegroups.com> >>> bugs@signedness.org writes: >>> >>>> On Aug 19, 10:43 pm, VAXman- @SendSpamHere.ORG wrote: >>>>> The code for this is 90(16), 144(10) bytes! I adhered to the calling >>>>> standard. There are some null quadwords in there (3) to maintain the >>>>> proper alignment too. It does NOT take much code to implement this. >>>>> Also, I was able to do this "silently", unlike those original demos. >>>>> This could be _easily_ weaponized. >>> My PoC for zapping AUTHPRIV is 172 bytes (116 code, 52 data+linkage), you >>> win. >> >> :) >> >> The idea was to keep it small as the *supported* mechanism I used allows >> for 252 bytes to be loaded! > > LIB$PUT_COMMON ? Yup. Why not? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Wed, 20 Aug 2008 23:40:08 GMT From: Malcolm Dunnett Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: VAXman- @SendSpamHere.ORG wrote: >>> The idea was to keep it small as the *supported* mechanism I used allows >>> for 252 bytes to be loaded! >> LIB$PUT_COMMON ? > > Yup. Why not? > No reason why not, seems a lot simpler than hunting around for the address of a logical name. ------------------------------ Date: Wed, 20 Aug 2008 19:59:55 -0400 From: "Richard B. Gilbert" Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: Neil Rieck wrote: > On Aug 7, 2:15 pm, Mark Daniel wrote: >> samp...@gmail.com wrote: >>> There's apparently an overflow flat in Multinet's Fingerd as well: >>> http://seclists.org/bugtraq/2008/Aug/0056.html >> This appears to behave as described on at least VAX VMS V7.3 MultiNet >> V5.1 Rev A-X but not on Alpha VMS V8.3 V5.2 Rev A-X or I64 VMS V8.3 V5.2 >> Rev A-X (three platforms I have access to). >> >> $ echo `perl -e 'print "a"x1000'` | nc -v host.name 79 >> Connection to host.name 79 port [tcp/finger] succeeded! >> >> I guess we can assume the 'group of lads' would be keeping an occasional >> eye on c.o.v. :-) >> > > I'm not sure if this is relavent, but I recently read something about > buffer overflow exploits in a book from "No Starch Press" titled > "hacking" (click http://www.nostarch.com/hacking2.htm ). > > Basically this is caused by bad C/C++ programming You can do bad programming in almost any language! Some languages make it easier and some make it more difficult. C/C++ are on the easy side of the spectrum. Ada does its best to make such games nearly impossible. Ada has never become really popular but it's heavily used where the code MUST BE RIGHT; in places like the space shuttle, certain medical equipment, and military software, the price of an error can be so high that it's worth sacrificing the creative freedom that is a feature of languages like C/C++, and assembler. Some hardware and O/S combinations can make this sort of thing more difficult by making the stack non-executable. ------------------------------ Date: Wed, 20 Aug 2008 23:31:34 GMT From: John Santos Subject: Re: Disk remains in HostUnavailable for a very long time Message-ID: In article <1219219494_339@isp.n>, n8wxs@arrl.net says... > JF Mezei wrote: > > Michael Moroney wrote: > >> This status is normal if communication with the remote MSCP server is > >> down, until the last status you gave where it was shown as mounted/remote > >> mount. Not sure why it didn't show up as available quicker, other than > >> the periodic MSCP "I'm available" message is a datagram which doesn't have > >> guaranteed delivery. > > > > > > Are there SYSGEN parameters on VAX (7.3) or on Alpha that might result > > in the Alpha realising that the VAX's disks are available again ? > > $ mcr sysgen > SYSGEN> use current > SYSGEN> set mystic_vision true > SYSGEN> write current > SYSGEN> ^Z > > > 8-) 8-) 8-) Isn't this a dynamic parameter? (I'd check for the "D" but I'm on my PC at the moment.) If so, change "current" to "active" and avoid the reboot. :-) :-) > > > > > > > > ----== 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 =--- > -- John ------------------------------ Date: Wed, 20 Aug 2008 11:48:57 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: DS10L power supply mystery Message-ID: <86efad5f-afdb-41d0-8276-1439d2c53b0c@a70g2000hsh.googlegroups.com> On Aug 20, 5:23 pm, "P. Sture" wrote: > In article > <6446e741-2f0a-49f5-9bbd-c860506a6...@z72g2000hsb.googlegroups.com>, > > > > johnwalla...@yahoo.co.uk wrote: > > Do you remember "Do Not Adjust Your Set"? (A UK kids programme, also to > be found on Youtube, and notable for Bonzo Dog Band and early > appearances of Eric Idle, Terry Jones etc.). > > -- > Paul Sture Vaguely recall DNAYS. It's apparently available on UK DVD (and, doubtless purely by coincidence, also lots of bits of DNAYS on Youtube). Under =A34 at amazon.co.uk, or $15 at Amazon.Com - at last, something more expensive on Amazon US than here in the UK! There's also a US-released 2-DVD set including both DNAYS and At Last It's The 1948 Show (UK readers beware, see reviews on Amazon.co.uk - half the material is missing in the UK 2-DVD equivalent). I guess DNAYS etc eventually led to things like Rutland Weekend TV (Idle, Innes, and friends), which I liked as much as some of the better-known bigger- budget stuff. Anything that brought the world The Rutles can't be all bad. ------------------------------ Date: Wed, 20 Aug 2008 12:40:44 -0700 From: Fred Bach Subject: Re: DS10L power supply mystery Message-ID: John Sauter wrote: > I don't remember where I first heard the term "crowbar" used to describe > this effect of power supplies, but I suspect it was taken from the old > method of stopping a flying platform: the pilot placed a crowbar between > the counter-rotating fans below him. The platform landed very quickly. > John Sauter (John_Sauter@systemeyescomputerstore.com) Back in the 60's when I was designing power supplies I was told the term came from the electric railway industry - apparently you could remove the power from an errant train by throwing a big enough literal crowbar across the rails. Recently I read an online discussion* about this. With the greater currents available these days it's more dangerous but apparently it is still done, rarely. I found it interesting that in the non-electric railroad industry the crowbar across the tracks will also declare that section of track as 'occupied' to the central office,** and prevent train access from adjacent sections. * http://cr4.globalspec.com/thread/24646/Diode-application reply #16 by PWSlack who was replying to reply #8 in the thread. ** see reply #22 in the above thread. We are familiar with the term 'crowbar' here when our big mercury-vapour ignitrons short out our 4-megawatt 20-kV power supply to protect the expensive equipment it powers from damage as a result of sparking. Given the fact that high-current arc discharges have a self-focusing effect, with that much power available a spark can burn a hole in copper cooling water lines. In fact, the way you test an anti-sparking crowbar circuit is by slowly moving a calibrated grounded copper sheet slowly up to a calibrated sparking point until a spark happens. Without the crowbar circuit detecting the spark and dumping the energy harmlessly through the ignitrons, the spark would blow a big hole in the copper plate. When the crowbar circuit is operating properly there will be no hole in the copper plate. .. Fred Bach music at triumf dot c a . ------------------------------ Date: Wed, 20 Aug 2008 20:43:23 +0000 From: ChrisQ Subject: Re: DS10L power supply mystery Message-ID: JF Mezei wrote: > Michael Moroney wrote: > > >> Nowadays power supplies usually have less crude protection logic, >> but often they require manual intervention such as removing power >> to reset them. > > > But power was completely out for a few hours last night... > > And because I had switched up the breaker for that room, the alpha > would not have seen transients when the power utility re-energized > the neighbourhoud. I waited over half an hour before putting the > breaker back to "ON". > > So you'd think a few hours without power would have reset the power > supply :-) > > Would you guys suggest I perform additional tests ? (cutting poower > abruptly and then applying it back some minutes later) ? My concern > is that if the power supply is "weak", such tests would weaken it > more. The most likely cause is a flakey psu. Main protection is still usually an scr (cheap, simple and works well), even if this is augmented in / by the switcher control circuit. I have a pc that won't fire up unless it's left powered down for 10mins or so before reapplying power. Dec, however, were not pc vendors and were very fussy about system testing. Something like that would have been spotted early on and would never have made it through product acceptance. Try a different psu... Chris ------------------------------ Date: Wed, 20 Aug 2008 14:20:40 -0400 From: "John Reagan" Subject: Re: lib$find_file on Pascal Message-ID: OK, make up your mind. Here or there... ? You didn't get enough information on how "dummy" is declared. VARYING OF CHAR? PACKED ARRAY OF CHAR? You also didn't say where you got the prototype of LIB$FIND_FILE from? SYS$LIBRARY:PAS$LIB_ROUTINES? Your private version? Here's an example that works: [inherit('sys$library:starlet', 'sys$library:pascal$lib_routines')] program find_file(input,output); var file_spec : varying [132] of char; result_spec : varying [132] of char; context : unsigned; ret_stat : unsigned; begin context := 0; write('Enter filespec to parse: '); while not eof do begin { Read the filespec from the user } readln(file_spec); { Loop and parse the file spec } repeat { Parse it... } ret_stat := lib$find_file( file_spec, %descr result_spec, { Use %DESCR to get CLASS_VS } context); if (not odd(ret_stat)) and (ret_stat <> RMS$_NMF) and (ret_stat <> RMS$_FNF) then lib$stop(ret_stat); if (ret_stat <> RMS$_NMF) and (ret_stat <> RMS$_FNF) then writeln(result_spec); until (ret_stat = RMS$_NMF) or (ret_stat = RMS$_FNF); { Clear LIB$FIND_FILE context } lib$find_file_end(context); { Get another file spec } write('Enter filespec to parse: '); end; end. Note the explicit use of %DESCR on the output argument for LIB$FIND_FILE. John ------------------------------ Date: Wed, 20 Aug 2008 23:58:54 +0200 From: Jan van Mastbergen Subject: Looking for a new home 2x MicroVAX 3100/10 Message-ID: Subject line says it all. I will need to retire to have the time to play with them, which won't happen in the next 11 years if at all. These are the server version, so headless. About 2.5 VUP. One of them is in working order, boots VMS 7.2, the other appears to have a disk that won't spin up anymore but otherwise ok. Various goodies included (VMS CD, TK50 cartridges, cables, thinwire repeater, terminators etc). These are in Nuenen, the Netherlands. Free for every one who appreciates these classics. Mail me if you're interested. No shipping. Regards, Jan ------------------------------ Date: Wed, 20 Aug 2008 22:34:00 -0700 (PDT) From: Enrike Subject: LTO3/LTO4 support from OpenVMS 7.2 / ALPHA Message-ID: <66169577-c6ae-4813-b81a-956f6d278359@m36g2000hse.googlegroups.com> I want some information about if OpenVMS 7.2 running in Alpha platform (ES47) supports a LTO3 or LTO4 tape unit Thanks in advance ------------------------------ Date: Wed, 20 Aug 2008 20:58:32 -0500 From: BRAD@rabbit.turquoisewitch.com (Brad Hamilton) Subject: SMGRTL patch available on ITRC ftp site Message-ID: Subject says it all. I'm off... ------------------------------ Date: Thu, 21 Aug 2008 03:03:51 GMT From: John Santos Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: In article , BRAD@rabbit.turquoisewitch.com says... > Subject says it all. I'm off... > IVES# set term/unknown IVES# mcr install INSTALL> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaA %CLI-W-TKNOVF, command element is too long - shorten (Pasting into my newsreader caused the new lines in the middle of all the "aaa"'s.) The uppercase A and the error message resulted when I hit the 1st uparrow. The 2nd uparrow recalled the long line of "aaa...aaa" and the 3rd uparrow echoed as another "A" and repeated the error message. No stack dump. No bogus jump, as far as I can tell. Looks to be fixed. (Patches available for I64 V8.2, V8.2-1, V8.3 and V8.3-1H1, and for VMS V7.3-2, V8.2 and V8.3. No patch for VAX of any version, at least not yet.) -- John ------------------------------ Date: 21 Aug 2008 04:37:32 GMT From: JONESD@ecr6.ohio-state.edu (David Jones) Subject: Re: SMGRTL patch available on ITRC ftp site Message-ID: Link time of the kit's SMGSHR.EXE: 7 weeks before release. 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. ------------------------------ End of INFO-VAX 2008.456 ************************