INFO-VAX Tue, 16 Sep 2008 Volume 2008 : Issue 508 Contents: Re: Getting started with an rx2600 Is there an updated Ghostscript for VMS? Re: Is there an updated Ghostscript for VMS? Re: Is there an updated Ghostscript for VMS? Re: Is there an updated Ghostscript for VMS? Re: Is there an updated Ghostscript for VMS? Re: License generator... Re: License generator... Re: License generator... Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: OT: The end of the world in roughly 3 hours Re: OT: The end of the world in roughly 3 hours Re: OT: The end of the world in roughly 3 hours Re: OT: The end of the world in roughly 3 hours Re: SDLT versus LTO tape backup Re: Security alarm msg ---------------------------------------------------------------------- Date: Mon, 15 Sep 2008 17:43:03 -0700 From: "Tom Linden" Subject: Re: Getting started with an rx2600 Message-ID: On Mon, 15 Sep 2008 10:12:07 -0700, wrote: > I just reseated all the RAM and it boots up into an EFI shell. Thanks! Great. Now here is the next great tip. When you write PL/I applications make sure you understand how ON conditions and signalling works so that you write safe, failsoft code, something that is rather more difficult to do in C. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Mon, 15 Sep 2008 16:24:20 -0700 From: Malcolm Dunnett Subject: Is there an updated Ghostscript for VMS? Message-ID: <48ceeea4$1@flight> I am using ghostscript 8.54 on my Alpha servers, using a kit that Mark Berryman build back in 2006. I have tried downloading the latest version, but the build fails with MMK spitting out a "syntax error" from one of the .mak files. Has anyone built a newer version of ghostscript for VMS? If so, any hints on how to get past this error (and on how well it works) Thanks in advance. ------------------------------ Date: Mon, 15 Sep 2008 19:44:26 -0400 From: "Richard B. Gilbert" Subject: Re: Is there an updated Ghostscript for VMS? Message-ID: Malcolm Dunnett wrote: > I am using ghostscript 8.54 on my Alpha servers, using a kit that Mark > Berryman build back in 2006. > > I have tried downloading the latest version, but the build fails with > MMK spitting out a "syntax error" from one of the .mak files. > > Has anyone built a newer version of ghostscript for VMS? If so, any > hints on how to get past this error (and on how well it works) > > Thanks in advance. How about fixing the failing line in the .mak file? ------------------------------ Date: Mon, 15 Sep 2008 18:57:42 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Is there an updated Ghostscript for VMS? Message-ID: <08091518574291_20202860@antinode.info> From: Malcolm Dunnett > I am using ghostscript 8.54 on my Alpha servers, using a kit that Mark > Berryman build back in 2006. > > I have tried downloading the latest version, but the build fails with > MMK spitting out a "syntax error" from one of the .mak files. > > Has anyone built a newer version of ghostscript for VMS? If so, any > hints on how to get past this error (and on how well it works) Assuming that your "the latest version" is 8.63, then it looks as if no one could have built it on VMS from _that_ kit. You can clear the worst of the initial complaints with changes like these: ALP $ gdiff OPENVMS.MMK_ORIG OPENVMS.MMK 278c278 < DEVICE_DEVS21= --- > ### DEVICE_DEVS21= 419c419 < .suffixes : .c .obj .exe --- > ### .suffixes : .c .obj .exe ALP $ gdiff DEVS.MAK_ORIG DEVS.MAK 422c422 < $(GLOBJ)lvga256.so: $(lvga256_) --- > $(GLOBJ)lvga256.so : $(lvga256_) 426c426 < $(GLOBJ)vgalib.so: $(vgalib_) --- > $(GLOBJ)vgalib.so : $(vgalib_) 530c530 < $(GLOBJ)X11.so: $(x11alt_) $(x11_) --- > $(GLOBJ)X11.so : $(x11alt_) $(x11_) 685c685 < $(RINKJ_OBJ)evenbetter-rll.$(OBJ): $(RINKJ_SRC)evenbetter-rll.c --- > $(RINKJ_OBJ)evenbetter-rll.$(OBJ) : $(RINKJ_SRC)evenbetter-rll.c 688c688 < $(RINKJ_OBJ)rinkj-byte-stream.$(OBJ): $(RINKJ_SRC)rinkj-byte-stream.c --- > $(RINKJ_OBJ)rinkj-byte-stream.$(OBJ) : $(RINKJ_SRC)rinkj-byte-stream.c 691c691 < $(RINKJ_OBJ)rinkj-device.$(OBJ): $(RINKJ_SRC)rinkj-device.c --- > $(RINKJ_OBJ)rinkj-device.$(OBJ) : $(RINKJ_SRC)rinkj-device.c 694c694 < $(RINKJ_OBJ)rinkj-config.$(OBJ): $(RINKJ_SRC)rinkj-config.c --- > $(RINKJ_OBJ)rinkj-config.$(OBJ) : $(RINKJ_SRC)rinkj-config.c 697c697 < $(RINKJ_OBJ)rinkj-dither.$(OBJ): $(RINKJ_SRC)rinkj-dither.c --- > $(RINKJ_OBJ)rinkj-dither.$(OBJ) : $(RINKJ_SRC)rinkj-dither.c 700c700 < $(RINKJ_OBJ)rinkj-epson870.$(OBJ): $(RINKJ_SRC)rinkj-epson870.c --- > $(RINKJ_OBJ)rinkj-epson870.$(OBJ) : $(RINKJ_SRC)rinkj-epson870.c 703c703 < $(RINKJ_OBJ)rinkj-screen-eb.$(OBJ): $(RINKJ_SRC)rinkj-screen-eb.c --- > $(RINKJ_OBJ)rinkj-screen-eb.$(OBJ) : $(RINKJ_SRC)rinkj-screen-eb.c ALP $ gdiff LIB.MAK_ORIG LIB.MAK 1222c1222 < $(GLOBJ)strmio.$(OBJ): $(GLSRC)strmio.c $(AK) \ --- > $(GLOBJ)strmio.$(OBJ) : $(GLSRC)strmio.c $(AK) \ ALP $ gdiff OPENVMS.MMK_ORIG OPENVMS.MMK 278c278 < DEVICE_DEVS21= --- > ### DEVICE_DEVS21= 419c419 < .suffixes : .c .obj .exe --- > ### .suffixes : .c .obj .exe And then it fails much more cleanly. Judging from all the non-space-separated colons, it's pretty clear that no one tests this stuff on VMS. At least not using MMK or MMS. At a glance, I'd guess that some actual work would be needed to make it go. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 15 Sep 2008 19:02:09 -0700 From: Malcolm Dunnett Subject: Re: Is there an updated Ghostscript for VMS? Message-ID: Steven M. Schweda wrote: > Judging from all the non-space-separated colons, it's pretty clear > that no one tests this stuff on VMS. At least not using MMK or MMS. At > a glance, I'd guess that some actual work would be needed to make it go. > Ah, I didn't realize MMK needed space-separated colons (I'm just an "end user" when it comes to makefiles). That certainly explains the syntax errors. Maybe I'll take a look at what it would take, OTOH the current VMS kit seems to do what I need (I just thought I'd update if one was available) > ------------------------------------------------------------------------ > > Steven M. Schweda sms@antinode-info > 382 South Warwick Street (+1) 651-699-9818 > Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 15 Sep 2008 22:01:50 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Is there an updated Ghostscript for VMS? Message-ID: <08091522015012_20202860@antinode.info> From: Malcolm Dunnett > > Judging from all the non-space-separated colons, it's pretty clear > > that no one tests this stuff on VMS. At least not using MMK or MMS. At > > a glance, I'd guess that some actual work would be needed to make it go. > > Ah, I didn't realize MMK needed space-separated colons (I'm just an > "end user" when it comes to makefiles). That certainly explains the > syntax errors. Some of them. The convention for UNIX "make" files is no space, but MMK and MMS demand a space to let the user specify a (VMS) colon-separated device name, something not found on UNIX. Anyone who doesn't use the VMS-accomodating space clearly isn't VMS-aware, so when you see problems like this, it's pretty likely that there will be other VMS-related problems, too. > Maybe I'll take a look at what it would take, OTOH the current VMS > kit seems to do what I need (I just thought I'd update if one was available) Looks to me like a significant project, but at one time, VMS was supported, so you could get lucky. SMS. ------------------------------ Date: Mon, 15 Sep 2008 20:34:18 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: License generator... Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , Mark McIntyre writes: > > > > Hobbyist licenses cost 12.5p per day, and include a huge number of > > products. > > Hobbyist licenses for VMS are free. They are free for DECUS (or whatever it is called this week), members, but that membership is, I think, not free in all countries. ------------------------------ Date: Mon, 15 Sep 2008 17:46:20 -0700 From: "Tom Linden" Subject: Re: License generator... Message-ID: On Mon, 15 Sep 2008 13:34:18 -0700, Phillip Helbig---remove CLOTHES to reply wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > >> In article , Mark >> McIntyre writes: >> > >> > Hobbyist licenses cost 12.5p per day, and include a huge number of >> > products. >> >> Hobbyist licenses for VMS are free. > > They are free for DECUS (or whatever it is called this week), members, > but that membership is, I think, not free in all countries. > We also provide free PL/I licenses for hobbysists, because we believe is all too brief to have to write code in C. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 16 Sep 2008 05:09:46 GMT From: John Santos Subject: Re: License generator... Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > In article , > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > >>In article , Mark McIntyre writes: >> >>>Hobbyist licenses cost 12.5p per day, and include a huge number of >>>products. >> >> Hobbyist licenses for VMS are free. > > > They are free for DECUS (or whatever it is called this week), members, > but that membership is, I think, not free in all countries. > It has been posted here many times that *anyone* can join the US chapter of DECUS as an associate member for free. You don't have to be a US citizen or resident. However, DECUS/Encompass now steers you to the Connect web site, and I can't find an equivalent of the old DECUS associate membership there. There is a "Guest" (free, limited time) membership, but it isn't clear if that allows you to get the VMS hobbyist licenses or how long the "limited time" is. Or if you can rejoin as a guest once a year to renew your hobbyist PAKs. I don't know if this is an oversight or a deliberate change in policy. There maybe other DECUS chapters (in other countries) with different policies and prices; maybe one of them would work better for the OP. That said, current individual membership is $50 (35 Euro) and is good through the end of next year. IIRC, DECUS used to be $90 for an individual membership. Cheaper than 1 year of Norton AntiVirus. :-) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Mon, 15 Sep 2008 12:24:48 -0700 (PDT) From: bugs@signedness.org Subject: Re: Loose Cannon-dian Message-ID: <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com> On Sep 15, 5:42=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <1cddb0fc-c644-4c38-9d33-0825a9a4b...@s50g2000hsb.googlegroups= .com>, b...@signedness.org writes: > > > > > So let me ask you what mechanisms VMS have in place to make it harder/ > > prevent buggy programs from being exploited? > > =A0 =A0On VMS, even if you have a fully priviledges account, you don't > =A0 =A0automagically get to exhaust any resource other than disk space. > =A0 =A0For all the others you have to add code to raise your limits. > Well obviously you can do that on UNIX too (change root's resource allocation).. But like you are pointing out if the attacker gets your admin account well then he can just raise his limits.... Which was exactly my point.. I pointed out that UNIX got that sort of resource allocation features too, but that it is not exactly a revolutionary security feature and when your security is breached and this particular feature is circumvented, getting DoS'd is usually the least of your concern.. > > W^X - Different vendors use different names, but the general idea is > > that by default a page that is writable is not executable. The idea is > > to prevent attackers from executing code in memory they control. > > =A0 =A0A great many hardware platforms won't support that, no matter what > =A0 =A0UNIX tries to do about it. Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha, Intel-64 and even i386 with some hacks to get around hardware limitations. Infact I think all decent sized open source UNIX kernel supports it to some extent, in many cases even on platforms where hacks are required to get around hardware limitations. Solaris also supports it, if I recall correctly TRU64 also used to have non-exec stack until they changed it to support java and other crap (see java is EVIL) So most "UNIX" you still see in production environments can actually do it.. > > > This is where UNIX has a real advantage and head start.. A LOT of > > people have been looking for and killing UNIX bugs for a very long > > time. Look at the bugs being discussed here, I doubt that you'll find > > that simple and exploitable stack overflows in any BSD, modern version > > of Solaris or even Linux (there are default binaries with simple stack > > overflows, but I'm talking about suid/sgid etc binaries where a bug > > potentially leads to a system compromise) > > =A0 =A0A lot of people have been looking for and killing VMS bugs for a > =A0 =A0long time, too. =A0There just haven't been as many. =A0Even back i= n the > =A0 =A0day when "get a VAX" was The Solution to almost every compute prob= lem > =A0 =A0and VMS was all over the networks, there weren't many. > The 3 of us have been doing this for about 10 years (looking for bugs), and we attend a lot of conferences around the world for people like us every year. So we know a fair amount of people in our "industry" and so far only one have said that at some point in time he thought about having a look at OpenVMS security (but he didn't). Out of the entire lot we know in the industry we can't name one who have actually looked at it... People were looking at in the 80s, we know this, we read the old hacking zines at textfiles.com... But..... There are new vulnerability classes and exploitation techniques being published all the time... Think Moore's law here.. and you'll get an idea how fast it evolves. I'm sure the people trying to break VMS security in the 80s were really good for their time, they did not however have the benefit of 20 years of published research we had since that. Take the format string bugs in finger, the technique to expoits those bugs were only made public around 2001. Maybe I would have agreed that VMS was cool from a security point of view 10-20 years ago, but today compared to the competition? I don't think so. If anyone had a serious go at finding vulns in VMS in the last 5-10 years, our defcon and our new bugs would have been fixed a long time ago. > > Just in case your counter argument is that we only found 3 bugs and > > argue that you can name more kernel vulns published in Linux this year > > alone... Keep in mind that we are only 3 people looking at it for fun, > > and only when we got a few minutes / hours to spare from doing "real > > work". =A0And our bug count is up to 5 reported bugs to HP now.. > > =A0 =A0The idea that quality software is impossible is one that I > =A0 =A0completely reject. Well nothing is impossible I guess. But when actual rocket scientists (NASA, ESA, whatever the russians call themselves) keep getting things like unit conversions wrong and it gets past what I would assume is fairly rigours QA (at least one would hope so considering the costs of blowing these things up...) I think you are going to have to wait a long time before your average programmer create quality softare without security bugs in something as complex as an operating system. Pretty much what we been saying all along is "if you don't look for these things then you are not going to find them but that does not mean you are secure". ------------------------------ Date: 15 Sep 2008 15:51:11 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Loose Cannon-dian Message-ID: <9mmVfkr+zemO@eisner.encompasserve.org> In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes: > > Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha, > Intel-64 and even i386 with some hacks to get around hardware > limitations. Are you claiming the UNIX kernel examines every instruction to see if it was read from data space? Just separating and marking the code read-only doesn't prevent executing writeable data space. It's been a long time since I saw an OS with both a user interface and default writeable code pages during execution. It was from M$. ------------------------------ Date: Mon, 15 Sep 2008 14:01:27 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: Loose Cannon-dian Message-ID: <3e9d55bc-97d2-4d2f-8aa1-efc55f7a84a7@a70g2000hsh.googlegroups.com> On Sep 15, 11:36 am, b...@signedness.org wrote: > On Sep 13, 10:30 am, johnwalla...@yahoo.co.uk wrote: > > > > > On Sep 12, 1:38 pm, koeh...@eisner.nospam.encompasserve.org (Bob > > > Koehler) wrote: > > > In article , Michael Kraemer writes: > > > > > This doesn't answer my question. > > > > The claim was that VMS is more secure than Unix, > > > > and I asked for certifications to prove that claim. > > > > But as far as I can see, VMS is just on par as > > > > far as obsolete criteria are concerned (C2/B1), > > > > and it is not certified at all for the more recent > > > > common criteria. > > > > The problem is the asumption behind your question. Just because > > > VMS is more secure than UNIX does not prove tham somone bothered > > > to write down a certification that covers the differences. > > > > Nor does the existence of a certification criteria make it the last > > > and complete word on security. > > > Indeed. I'll ask the community again, what mechanisms do best > > practices on various Windozes and Unixes have to prevent a resource- > > exhaustion Denial of Service, one which on a properly managed VMS is > > easily preventable, but which (from what I've seen to date) is > > impossible to prevent on many other OSes. What do the Common Criteria > > have to say on the subject, or is a resource exhaustion DoS a figment > > of my imagination ? > > > On a desktop OS you probably don't care about this, and on a desktop- > > derived server OS you probably can't care about this, but on a true > > multi-tasking multi-user OS serving one or more business-critical > > applications, it ought to be of more interest. If the underlying OS > > doesn't have the necessary real-time resource accounting capability > > built in, best for the industry if they keep quiet about it?- Hide quoted text - > > > - Show quoted text - > > To answer your question, it is possible to do in UNIX too. For example > seehttp://www.freebsd.org/doc/en/books/handbook/users-limiting.html > > This can protect you from simple resource exhaustion attacks, and > while that is cool it doesn't necessary make you any more secure. If > someone exploits a privileged program or the kernel to obtain root/ > SYSTEM access then they can still DoS you back to the stone age, but > more likely they steal/modify your data which in almost all cases is > even worse than *just* disrupting a service. > > So let me ask you what mechanisms VMS have in place to make it harder/ > prevent buggy programs from being exploited? > > On UNIX we have among other things: > > W^X - Different vendors use different names, but the general idea is > that by default a page that is writable is not executable. The idea is > to prevent attackers from executing code in memory they control. > > ASLR - Address space layout randomization. With W^X alone, overwriting > stack return address and returning into a library function would be > trivial. ASLR makes that much harder since the address of the function > the attacker wants to return to is not known to him. > > Compiler hacks - Stack canaries/cookies etc, an overwriten return > address on the stack for example will be detected before the return > branch is taken. > > "Even" Windows supports these features with DEP, Vista got ASLR, and > their compiler had the /GS switch for stack protection for quite some > time now. > > Of course these features are not perfect. There are special cases > where they are trivial to by pass even. They do help, but the only > real solution to getting secure is to look for and fix security bugs > not trying to compensate by introducing features that makes it harder > to exploit them. > > This is where UNIX has a real advantage and head start.. A LOT of > people have been looking for and killing UNIX bugs for a very long > time. Look at the bugs being discussed here, I doubt that you'll find > that simple and exploitable stack overflows in any BSD, modern version > of Solaris or even Linux (there are default binaries with simple stack > overflows, but I'm talking about suid/sgid etc binaries where a bug > potentially leads to a system compromise) > > Just in case your counter argument is that we only found 3 bugs and > argue that you can name more kernel vulns published in Linux this year > alone... Keep in mind that we are only 3 people looking at it for fun, > and only when we got a few minutes / hours to spare from doing "real > work". And our bug count is up to 5 reported bugs to HP now.. Are we on the same wavelength here? Hopefully yes. Decent OSes whose heritage is multiuser multitasking tend to have at least some level of protection against resource exhaustion issues. Readers (if there are any left) are still waiting for the answer for OSes whose origin is desktop (you know the one I mean). If folk can get root/SYSTEM access there are indeed much more serious things to worry about than resource exhaustion (loss of data, unintended export of data, etc), but if users can get unauthorised execution of unprivileged code and cause a resource exhaustion DoS, that could be inconvenient too. It's a shame VMS on Alpha didn't do anything useful with "fault on execute" in the PTE. But it's now largely irrelevant, because Itanium does (iirc) have the "non executable pages" stuff. And AMD64 certainly does. ASLR is something mentioned earlier in this thread (I thought?). Afaict the whole ASLR band-aid/concept is foreign to (and incompatible with) VMS's use of transfer vectors so that applications can if they so wish call the same runtime libraries at the same addresses regardless of version changes. The code itself may move, but the transfer vector deliberately stays at the same place, so what's the point in randomising anything? In VMS land this kind of design decision is called "investment protection", and it's an OS design-time decision which made sense back then, and arguably still makes sense today (just ask anyone who's experienced the SxS nightmare on Windows when you need to support one app version on multiple OS versions). Same as the decision to include assorted resource quotas is pretty much set in stone when the OS is designed (you can choose to enforce them or not, or set sensible values or not, but if they're not architected right they can't be retrofitted externally). In respect of your later post: re who's been looking at VMS security and when: did you know that the VMS listings were widely available (for free, iirc) inside DEC, and were available for a relatively small fee to customers (systems houses, etc) outside DEC ? They may still be available, I don't know. And did you know that VMS Internals and Data Structures courses for employees and outsiders were relatively common and sometimes went into great detail, sometimes even more than is in The I+DS Book? Consequently the number of people who have seen inside VMS is perhaps larger than you think, and the number of *interested*, *competent*, *knowledgeable* people who've looked inside in the past is almost certainly larger than you seem to imagine. Whether that's helped make VMS more secure is a more difficult question to answer; the people that may know are unlikely to comment here. You have yourself found holes which ought not to have been there, but have other holes been fixed as a result of folks poking around in the source listings? It's like the "peer review" argument for FOSS isn't it? One final note re: "you are going to have to wait a long time before your average programmer create quality softare without security bugs in something as complex as an operating system. " Seems very fair. From which I conclude that folks who care about quality, security, etc would be well advised not to use an OS architected by (not just written by) "average programmers". The same also goes for compilers, runtime libraries, and the like. Others may well draw a different conclusion :) I can't comment on the current state of DEC/CPQ/HP compilers and runtimes but those I have known in the past have never lacked the facilities I've needed (or the facilities my customers have needed) and have often set the standard for the industry to compare with (Fortran and Ada were known to me, but there were others too. Then there was VAX C, which is probably best forgotten). Again with compilers and runtimes we see the importance of *architecture* as well as implementation. MS have finally realised that a common language runtime might be a bright idea. VMS shipped its common language runtime (based on the language-independent "calling standard", common structure definition language, and the like) back in 1978, and common code generators (compiler backends etc) were also in early use. A decent architecture doesn't prevent rubbish code, but a rubbish architecture can easily make rubbish code more dangerous. ------------------------------ Date: 15 Sep 2008 16:09:48 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Loose Cannon-dian Message-ID: In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes: > > The 3 of us have been doing this for about 10 years (looking for > bugs), and we attend a lot of conferences around the world for people > like us every year. So we know a fair amount of people in our > "industry" and so far only one have said that at some point in time he > thought about having a look at OpenVMS security (but he didn't). Out > of the entire lot we know in the industry we can't name one who have > actually looked at it... People were looking at in the 80s, we know > this, we read the old hacking zines at textfiles.com... But..... So, you're behind the times, trying to catch jup, and making broad claims about the state of security in an OS you're still learning? That's not a lot of credibility where I come from. > > There are new vulnerability classes and exploitation techniques being > published all the time... Think Moore's law here.. and you'll get an > idea how fast it evolves. I'm sure the people trying to break VMS > security in the 80s were really good for their time, they did not > however have the benefit of 20 years of published research we had > since that. Take the format string bugs in finger, the technique to > expoits those bugs were only made public around 2001. Maybe I would > have agreed that VMS was cool from a security point of view 10-20 > years ago, but today compared to the competition? I don't think so. 20 years of published research on how to hack into poorly designed and/or implemented systems may not apply to a system mostly ignored by those researchers. > Well nothing is impossible I guess. But when actual rocket scientists > (NASA, ESA, whatever the russians call themselves) keep getting > things like unit conversions wrong and it gets past what I would > assume is fairly rigours QA (at least one would hope so considering > the costs of blowing these things up...) I think you are going to have > to wait a long time before your average programmer create quality > softare without security bugs in something as complex as an operating > system. I'm not about to accuse VMS Engineering of being "average programmers". OS complexity is often a result of poor design. What I can see is that UNIX and Windows security design makes it easy to screw up. VMS security design makes it easy to get things right (more about that below). And lots of stiudies have shown that rigorous QA actaully can become an excuse for poor work. ("QA will catch it if it's wrong." "It must be good enough, QA passed it.") Sure, you can get things right in UNIX and you can screw up in VMS, but you don't get a feel for impact of design decisions all that fast. SUID, SGID, and all or nothing privileges have been tripped over so many times as to make thier inherint difficulties obvious. VMS didn't have the equivalent of SUID or SGID for a long, long, time, and implemented it in a way that made it easy to use, optional to turn on, and completely unjustified to use it like SUID 0. A lot of modern UNIX now have finer grains of privilege, like VMS has always had, but when you use a file's mode to SUID 0, what good did that granularity do you? These are just some of the reasons that people who did look for vulnerabilities didn't find many, and soon chose easier targets. I could go on, but you're not listening. ------------------------------ Date: Mon, 15 Sep 2008 22:14:03 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: Loose Cannon-dian Message-ID: <00A7FACE.27383E58@SSRL.SLAC.STANFORD.EDU> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >In article <79a5a519-283f-4b25-99e6-778a49046cb5@m45g2000hsb.googlegroups.com>, bugs@signedness.org writes: >> >> The 3 of us have been doing this for about 10 years (looking for >> bugs), and we attend a lot of conferences around the world for people >> like us every year. So we know a fair amount of people in our >> "industry" and so far only one have said that at some point in time he >> thought about having a look at OpenVMS security (but he didn't). Out >> of the entire lot we know in the industry we can't name one who have >> actually looked at it... People were looking at in the 80s, we know >> this, we read the old hacking zines at textfiles.com... But..... > > So, you're behind the times, trying to catch jup, and making broad > claims about the state of security in an OS you're still learning? > > That's not a lot of credibility where I come from. I think you're making good points, but this is basically an argument you can't win. Their position is that they didn't know much about the system, didn't try very hard, and found some vulnerabilities, at least one of which has now resulted in a MUP to fix a 20+ year old problem. At this point we're better off saying "thank you, and keep up the good work" than in arguing from first principles about how the better engineering and the internal code review and the good design means that there are fewer vulnerabilities than in other systems which have been bashed on harder than VMS has during, oh, the entire lifetime of the commercial internet. -- Alan ------------------------------ Date: Mon, 15 Sep 2008 15:26:55 -0700 (PDT) From: bugs@signedness.org Subject: Re: Loose Cannon-dian Message-ID: <3be1632c-359d-40e3-acc8-40c1bbea9737@x41g2000hsb.googlegroups.com> On Sep 15, 9:51=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <79a5a519-283f-4b25-99e6-778a49046...@m45g2000hsb.googlegroups= .com>, b...@signedness.org writes: > > > > > Well OpenBSD for example supports it on SPARC, AMD64, PA-RISC, Alpha, > > Intel-64 and even i386 with some hacks to get around hardware > > limitations. > > =A0 =A0Are you claiming the UNIX kernel examines every instruction to see > =A0 =A0if it was read from data space? =A0Just separating and marking the > =A0 =A0code read-only doesn't prevent executing writeable data space. > No thats not what I said. I said most modern ones running on "modern" platforms with poor hardware support (no NX bit) do implement work arounds.. I did not say a word on how they implement that.. Funny you accuse me of not listning.. Anyway if you are interested I believe some openbsd developer have done a write up on it, if you can't find it there is always the source if you want to know how it works.. If you prefer a simple test, I have written one for you.. #include #include #include int f(); int main() { char payload[16]; int (*f)(); int x; strcpy(payload,"\x31\xc0\xb0\x2a\xc3"); f=3D(void *)&payload; x=3Df(); printf("%d\n",f()); return 0xbadc0ded; } For those of you not fluent in x86 opcodes, what goes into "payload" is simply this: xor eax,eax mov al,42 ret The calling standard says eax is the register a function returns its return value in... Payload is located on the stack (more on that later) so if we got an executable stack it will print 42 otherwise it will crash. So lets test it on FreeBSD which does not support this particular feature by default $ uname -a FreeBSD denial 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ cc stack_test.c -Wall $ ./a.out 42 OK cool... it works, code execution on the stack like expected.... Same thing on NetBSD which happens to have a non executable stack on i386 by default $ uname -a NetBSD 4.0 NetBSD 4.0 (GENERIC) #0: Sun Dec 16 00:20:10 PST 2007 builds@wb34:/home/builds/ab/netbsd-4-0-RELEASE/i386/200712160005Z-obj/ home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/i386/compile/GENERIC i386 $ cc stack_test.c -Wall -g $ ./a.out [1] Segmentation fault (core dumped) ./a.out Maybe you think it crashed for some other reason? Ok... lets find out $ gdb -q a.out (gdb) run a.out Starting program: /home/christer/a.out a.out Program received signal SIGSEGV, Segmentation fault. 0x08048705 in main () at stack_test.c:16 16 x=3Df(); (gdb) p f $1 =3D (int (*)()) 0xbfbfeccc (gdb) info reg esp esp 0xbfbfecc0 0xbfbfecc0 (gdb) x/5bx 0xbfbfeccc 0xbfbfeccc: 0x31 0xc0 0xb0 0x2a 0xc3 It crashed on the function call trying to execute stack memory... Look at the function pointer and compare it to the stack pointer it is actually on the stack... and finally lets just make sure we copied the right data into our stack function and that didn't fuck up somehow.. Well what do you know, it was actually the non-executable protection that caught it!!! On i386! > =A0 =A0It's been a long time since I saw an OS with both a user interface > =A0 =A0and default writeable code pages during execution. =A0It was from = M$. Unless you are talking about versions earlier than win95 I'd like you to show me writable code pages on windows by default.. ------------------------------ Date: Mon, 15 Sep 2008 16:49:01 -0700 (PDT) From: bugs@signedness.org Subject: Re: Loose Cannon-dian Message-ID: On Sep 15, 10:09=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <79a5a519-283f-4b25-99e6-778a49046...@m45g2000hsb.googlegroups= .com>, b...@signedness.org writes: > > > > > The 3 of us have been doing this for about 10 years (looking for > > bugs), and we attend a lot of conferences around the world for people > > like us every year. So we know a fair amount of people in our > > "industry" and so far only one have said that at some point in time he > > thought about having a look at OpenVMS security (but he didn't). Out > > of the entire lot we know in the industry we can't name one who have > > actually looked at it... People were looking at in the 80s, we know > > this, we read the old hacking zines at textfiles.com... But..... > > =A0 =A0So, you're behind the times, trying to catch jup, and making broad > =A0 =A0claims about the state of security in an OS you're still learning? I think you deliberately are trying to misunderstand me. What I was trying to say was that VMS is behind the times because nobody have done any serious bug hunting on it since the 80s, which results in bug classes that are virtually extinct in other environments were found in a matter of hours by someone with absolutely no prior experience with VMS. > > =A0 =A0That's not a lot of credibility where I come from. > Ok, how about the fact that we each have about 10 years of experience looking for security bugs in MANY MANY different operating systems and applications? Does that give us any credibility? Or make us at least a tiny bit qualified to talk about what type of bug classes you don't ever see in well tested, high quality software anymore? Probably not as long as we don't tell you what you want to hear, right? > > > > There are new vulnerability classes and exploitation techniques being > > published all the time... Think Moore's law here.. and you'll get an > > idea how fast it evolves. I'm sure the people trying to break VMS > > security in the 80s were really good for their time, they did not > > however have the benefit of 20 years of published research we had > > since that. Take the format string bugs in finger, the technique to > > expoits those bugs were only made public around 2001. Maybe I would > > have agreed that VMS was cool from a security point of view 10-20 > > years ago, but today compared to the competition? I don't think so. > > =A0 =A020 years of published research on how to hack into poorly designed > =A0 =A0and/or implemented systems may not apply to a system mostly ignore= d > =A0 =A0by those researchers. > Why don't you read what I said, I even gave you an example... let me break it down for you.. 1) One of the finger bugs we found is a format string vulnerability 2) The exploitability (or at least the technique that makes this bug exploitable) was not publically known until around 2001 3) That is where the 20 years of published research comes in... The people looking at VMS security in the 80s didn't know format string bugs were exploitable > > Well nothing is impossible I guess. But when actual rocket scientists > > (NASA, ESA, whatever the russians call themselves) =A0keep getting > > things like unit conversions wrong and it gets past what I would > > assume is fairly rigours QA (at least one would hope so considering > > the costs of blowing these things up...) I think you are going to have > > to wait a long time before your average programmer create quality > > softare without security bugs in something as complex as an operating > > system. > > =A0 =A0I'm not about to accuse VMS Engineering of being "average > =A0 =A0programmers". =A0OS complexity is often a result of poor design. = =A0What > =A0 =A0I can see is that UNIX and Windows security design makes it easy > =A0 =A0to screw up. =A0VMS security design makes it easy to get things ri= ght > =A0 =A0(more about that below). =A0And lots of stiudies have shown that > =A0 =A0rigorous QA actaully can become an excuse for poor work. =A0("QA w= ill > =A0 =A0catch it if it's wrong." =A0"It must be good enough, QA passed it.= ") > I don't know where you seen those studies, I certainly never read them and I have done QA for a large company in the security industry. > =A0 =A0Sure, you can get things right in UNIX and you can screw up in VMS= , > =A0 =A0but you don't get a feel for impact of design decisions all that > =A0 =A0fast. In all fairness I don't think we talked about design decisions much yet.. I believe 99% what we talked about so far has been implementation bugs (exploitable code) and the fact it has not been tested much by "hackers". We could talk about design too but it would be a very long discussion.... And believe me there are lots of things I don't like in the UNIX design too. Like I said before I'm not religous about my operating systems (even run lots of windows boxes - laugh if you want, but it is actually not that bad) > > =A0 =A0SUID, SGID, and all or nothing privileges have been tripped over s= o > =A0 =A0many times as to make thier inherint difficulties obvious. =A0VMS > =A0 =A0didn't have the equivalent of SUID or SGID for a long, long, time, > =A0 =A0and implemented it in a way that made it easy to use, optional > =A0 =A0to turn on, and completely unjustified to use it like SUID 0. =A0A > =A0 =A0lot of modern UNIX now have finer grains of privilege, like VMS ha= s > =A0 =A0always had, but when you use a file's mode to SUID 0, what good di= d > =A0 =A0that granularity do you? There is no denying early UNIX fucked a lot of things up. Even with just the user/group and suid/sgid model they could have made things much much better. But you know what? The difference is that they have admitted to their mistakes and are doing things to fix them and there are still a lot of things for them to do, but they have done than VMS in recent years. It is funny you should mention SUID 0.. Yes great care must be taken when you give a "user controlled" process euid 0.. But you have the same problem with VMS don't you? Only there the privs are called BYPASS, SETPRV, CMKRL, SYSPRV etc but essentially those and a few more mean the same thing as uid/euid 0 - complete control over the system. Even HP acknowledges this although I can't find the link right now. If you want to be in denial about security flaws in VMS that is your choice, and you'll be glad to hear we don't have any more conferences planned so we don't have to update our slides and are unlikely to look for more bugs in VMS unless a client asks us. > =A0 =A0These are just some of the reasons that people who did look for > =A0 =A0vulnerabilities didn't find many, and soon chose easier targets. Even if that was true (that they didn't find many in the 80s) I already explained that new type of attacks and techniques are found all the time and evolve really fast. So the fact that people looking for vulns in the 80s didn't find much doesn't mean there were not many bugs. And some of the bugs that people missed (or maybe simply didn't report) in the 80s we found in a couple of hours and as everybody in this group pointed out more than a few time we don't even know the operating system! I would like to say the reason why we found 3 exploitable local vulnerabilities and two remotely exploitable vulnerabilities that quickly is because of our super-human bug hunting skills but I'd be lying.. The simple truth is that nobody had looked for exploitable bugs in VMS for a very long time so there was/is a lot of "low hanging fruit". > =A0 =A0I could go on, but you're not listening. ------------------------------ Date: Mon, 15 Sep 2008 12:09:51 -0700 (PDT) From: AEF Subject: Re: OT: The end of the world in roughly 3 hours Message-ID: <74117e75-f9b6-469e-a3c6-57781f61d242@m45g2000hsb.googlegroups.com> On Sep 15, 12:51=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article , AEF writes: > > > > > As for running the accelerator itself and its detectors and what not > > -- I really don't know. I know that people in the physics group I was > > in at graduate school used to use VAX/VMS and recently (if not still) > > use Linux to analyze their data. Uh, they phased out VAX/VMS in the 1990's and phased in Linux and both were to analyze data. At least one accel. lab I know was switching from VMS to Unix for online data acquisition ca. 1990, but that's the word when I was there ca. 1987. As for what ran the accelerator itself, I never knew. Others ran it at the other end of the very long building. All we cared was that we got beam. Got beam? :-D > > =A0 =A0I don't know about running the accelerator, but when I was introdu= ced > =A0 =A0to particle physics I was told that you "collect your data on a > =A0 =A0PDP-11 and analyze it on a PDP-10". > > =A0 =A0That was a couple years before DECshipped the first 11/780. =A0The > =A0 =A0particle physics group bought the cheapest system DEC would ship: > =A0 =A01MB RAM, 64MB disk (I think), one 9 track, one LA36, no FPA. =A0We > =A0 =A0added 1 DZ-11. No FPA?! When I was "replaying my data", our FPA died and I actually felt it in reduced speed. Then I measured it and -- lo and behold it went from ~ 27 events / CPU-sec down to ~ 18 events / CPU-sec, IIRC. I asked system management to look into it and they said the FPA died. I didn't even know we had one, much less that there were such creatures. So what did you have? A VAX 11/750? AEF ------------------------------ Date: Mon, 15 Sep 2008 20:32:58 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: OT: The end of the world in roughly 3 hours Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , AEF writes: > > > > As for running the accelerator itself and its detectors and what not > > -- I really don't know. I know that people in the physics group I was > > in at graduate school used to use VAX/VMS and recently (if not still) > > use Linux to analyze their data. > > I don't know about running the accelerator, but when I was introduced > to particle physics I was told that you "collect your data on a > PDP-11 and analyze it on a PDP-10". > > That was a couple years before DECshipped the first 11/780. The > particle physics group bought the cheapest system DEC would ship: > 1MB RAM, 64MB disk (I think), one 9 track, one LA36, no FPA. We > added 1 DZ-11. Even not-adjusted for inflation, for that money, how many new Itanium systems could you buy? And what would there collective performance in VUPs be? Time was, whatever branch of the physical sciences (or perhaps biological sciences as well), data was collected and analysed on VMS systems. Those days are largely gone. ------------------------------ Date: 15 Sep 2008 15:52:45 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: OT: The end of the world in roughly 3 hours Message-ID: In article <74117e75-f9b6-469e-a3c6-57781f61d242@m45g2000hsb.googlegroups.com>, AEF writes: > > So what did you have? A VAX 11/750? No. As I said it was an 11/780. 11/750 had not yet been announced. ------------------------------ Date: Mon, 15 Sep 2008 22:07:38 GMT From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) Subject: Re: OT: The end of the world in roughly 3 hours Message-ID: <00A7FACD.41C26121@SSRL.SLAC.STANFORD.EDU> In article <003c2467-7e1d-44db-aef0-d4b35e140a7e@l42g2000hsc.googlegroups.com>, DaveG writes: >On Sep 14, 1:05=A0am, wins...@SSRL.SLAC.STANFORD.EDU (Alan Winston - (snippage of my quote) > >Has the linear accelerator that paralles the San Andreas been shaken >not stirred lately? Parallels? I think it _crosses_ it. We got whacked very hard in 1989; no particular earthquake trouble since, as far as I know. (My part of the lab, the synchrotron part, now runs a dedicated injector - an accelerator of its own, although it's circular, not linear - so we aren't at the mercy of the big linac. The LCLS project, finishing construction now, does use the first third of the linac. -- Alan ------------------------------ Date: Mon, 15 Sep 2008 15:26:21 -0400 From: "Carl Friedberg" Subject: Re: SDLT versus LTO tape backup Message-ID: <890539d90809151226vb4bc69av80edb14a169fac73@mail.gmail.com> Any experience / comments re HP StorageWorks 1/8 G2 LTO-4 Ultrium 1760 SCSI Tape Autoloader AJ816A? Thanks, Carl Friedberg carl@nospamcomets.com On Sun, Sep 14, 2008 at 4:26 PM, wrote: > Rob wrote: >> On Sep 11, 8:02??pm, Alan Frisbie >> wrote: >> > I have been a happy user of DLT/SDLT tapes for many years. >> > One of my sites is currently using SDLT 160/320, but the >> > backups are now taking two tapes and they want to upgrade. >> > >> > The next logical step up is SDLT 300/600 (SDLT-II tapes), >> > but I want to consider other options. ?? One option is the >> > LTO-3 (400 GB / 800 GB) drive. >> > >> > I would to know your opinions on these two options, plus >> > any others you might be using. ?? I hear some people saying >> > that SDLT is dead and the future is LTO, but other disagree. >> > >> > What do *YOU* use for your most valuable data, and why? >> > >> > Thanks, >> > Alan Frisbie > >> We went from DLT4 to SDLT to LTO3. LTO3 has certainly been the most >> stable, with only one drive swap so far. You can also mix SDLT and LTO >> in a MSL6000 library, although I believe LTO3 will also read-only >> SDLT. Please check these facts on the HP support matrix. > > I was looking into mixing SDLT and LTO and the document I found > said the following about mixing SDLT and LTO in the MSL6000 (and > MSL5000 as well): > > MSL libraries will not support SDLT and Ultrium cartridges in the same > library module because of differences in media magazine size. However, > support for MSL libraries with SDLT and Ultrium drives in separate > modules in a multi-unit stack is supported. > > I found the documentation here: > > http://h18006.www1.hp.com/products/storageworks/tapecompatibility.html > > The specific document was: > > ftp://ftp.compaq.com/pub/products/storageworks/techdoc/tapestorage/ > SW_MSL_Tape_Auto_bc_FINAL.hires_040808.pdf > (that URL is split) > > Which was linked from "Tape compatibility" -> "Business class libraries > drive upgrade matrix". > -- > Eric Dittman > dittman@dittman.net > ------------------------------ Date: Mon, 15 Sep 2008 13:57:14 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Security alarm msg Message-ID: <08091513571447_20202860@antinode.info> From: Michael Unger > Well, according to the RIPE database [1] these network is spread around > the whole world -- it's not "just China": > > | The country is really worldwide. > | This address space is assigned at various other places in > | the world and might therefore not be in the RIPE database. > > Michael > > [1] > The useful bit here was, "and might therefore not be in the RIPE database". If you want actual information, it's useful at start at the top: http://ws.arin.net/whois/ which, for Asia, will typically refer you to: http://www.apnic.net/apnic-bin/whois2.pl which may send you to Korea: http://whois.nida.or.kr/ and so on. RIPE is good for Europe, but little else, although it might remember enough to refer you to the African site if you feed it one of those addresses which it formerly handled. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ End of INFO-VAX 2008.508 ************************