Got pointed to this recent DEFCON presentation on OpenVMS. We're glad to see after all this time, there's still references to OpenVMS at DEFCON. The foray into the Lions Den by a group of Dallas folks is even mentioned in the talk. But, it's an excellent example that even one of the most secure operating systems can still be compromised by bad coding. And even from within OpenVMS Engineering. In particular, the TCP/IP team. Which managed to be bug-compatible with other similar functions. A very interesting talk.
My only critique of the session is "People still run 'finger' on OpenVMS?" Apparently so. A tip o' the hat to Dave Smith from the UK for letting me know about this.
maverion March 07 2011 10:27
The video was good and well worth the view.
Sort of shows what happens when OpenVMS starts importing all the non-native tools / stacks etc into it doesn't it?
Still, at the end of the day it shows up security flaws - whether non-native or not and it has the potential to shake existing and future OpenVMS houses.
If HP were smart, they would hire some unix guru's to go over all the various stuff that has been imported into OpenVMS to ensure it doesn't fall to more of these exploits/ As these people pointed out - these are basic exploits in unix, which sort of implied what else was out there!
A lot of people are staying with OpenVMS because of it's perceived security - if they let that image walk out the door there will be a flood away from it.
With HP wanting to bring more and more cross-porting functionality to OpenVMS, one has to wonder what else is going to come across?
Being an OpenVMS advocate myself this video was hard to take in some ways as it stood in the face of many a year of belief that OpenVMS was inherently secure - let's hope all of us OpenVMS folk realise what's at stake here if we sit back and ignore this shot across the bow.
We can all laugh at Windows and unix for lots of things but one thing they do have is an active presence in the security arena and they are not afraid to see the dark side of their OS's in terms of exploits - I feel a number of OpenVMS users are not like this relying more upon historical notions of OpenVMS security than realising all the imported code into OpenVMS can sometimes bite us
Sad to think that in some ways HP must have not rewritten the code from the ground up with OpenVMS design philosophy in mind and instead went the cut and paste route. Still - this is what we have to deal with now.
medhurstton April 07 2011 19:48
Re : "Sort of shows what happens when OpenVMS starts importing all the non-native tools / stacks etc into it doesn't it?"
Maybe I misunderstood the exploit, but didn't it centre on the CLI 511 character then up-arrowx3 bug rather than the application it was triggered within?
That would squarely make it an OpenVMS problem although there is a fair argument that a crash within TELNET|TCP/IP ought to be handled by the application better too.
JCEon September 16 2011 04:57
Just want to update any who view on comments from the OpenVMS Team...
The Defcon 16 slides mainly talk about 2 exploits on OpenVMS. Both of these exploits were fixed more than two and a half years ago. The details about the fixes are given below:
1. The Screen Management overflow vulnerability - This issue was fixed in August 2008 and SMGRTL patches were made available for all affected VAX, Alpha and Integrity versions of OpenVMS.
A bulletin was also issued during the time (note: links may have changed or require account login to view):
ITRC URL: http://www13.itrc.hp.com/service/cki/docDisplay.do?docId=emr_na-c01539423
BSC URL: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01539423
SAW URL: http://saw.cce.hp.com/km/saw/view.do?docId=emr_na-c01539423
2. Finger Client Format String vulnerability - This issue was fixed in September 2008 and images were provided for TCPIP V5.4 ECO 7, V5.5 ECO 3, and V5.6 ECO 2. This fix was also included in the subsequent TCPIP V5.6 ECO 3.
Please note that all update kits since Sep 2008 have the necessary fixes.
In addition to the above fixes, OpenVMS security as well as multiple teams from OpenVMS engineering have investigated and fixed 16 other vulnerabilities since 2009. These include