Share with your network!
Sometimes I feel I am very old. I was born in the same year as Bill Gates and Steve Jobs, and have watched the microprocessor revolution from the beginning. What a long strange trip it's been.
My first experience of writing programs was painfully inscribing FORTRAN with a ball point pen on paper. This was transcribed by a key punch operator onto punched cards, and run on an ICL 1900 mainframe several miles away. I just worked out the other day that the data I am carrying around in my pocket would take a stack of punched cards twenty miles high to contain it, and a data warehouse the size of Google's would take a stack of punched cards from here to the Sun. That's a lot of dead trees.
The ICL 1900 had 24 byte words consisting of four six-byte characters and 15 bit addressing. That architecture did not last, and by the time I was getting paid to program in the late 1970s it was on an IBM 360/168. The programs I worked on then would still run on today's IBM mainframes, and possibly still are. In 1985 I was working as a consultant doing some financial modeling for Bank of America, and was assigned to a desk with an IBM PC/AT which was running a 3270 terminal emulator talking to one of B of A's mainframes. I got tired of waiting for batch jobs to turn around on the mainframe, so suggested we get a FORTRAN compiler for the PC, so that I could work on that.
I don't believe I've worked on a mainframe since then. However, the memories came flooding back at Defcon when I listened to Philip Young and Chad Rikansrud give a talk entitled Security Necromancy: Further Adventures in Mainframe Hacking. Those old familiar acronyms: JCL, CICS, PL/1, and the strangely familiar mnemonics of IBM assembler language. Yes, I cut my engineering teeth on that stuff, and it is strangely comforting to know that it is still out there. If this whole Internet thing turns out to be a flash in the pan, at least I have something to fall back on.
As the presenters pointed out, you may think of mainframes as dinosaurs, but they are still used by 90% of the Fortune 100, and any time you use a credit card, get cash from an ATM, or book a flight you are using a mainframe. Last year IBM's revenues were larger than those of Google and Facebook put together. If you need massive IO bandwidth going into a single reliable database, you need a mainframe. IBM pioneered the use of channels, that is, dedicated processors to manage IO, so that the extremely expensive CPU could be kept as busy as possible without having to wait for disks to return data. Back when Cray Research made the fastest supercomputers, an old friend of mine (hi nic) was hired by them to write code for an IBM mainframe to talk to a Cray. It raised some eyebrows when he showed that the IBM could write data faster than the Cray could read it.
So mainframes are still out there, and provide a vital part of the computing infrastructure for most large corporations. Young and Rikansrud pointed out that IBM does not publicly report vulnerabilities. To be fair, it has been managing its bugs and vulnerabilities internally since long before the CVE system, and doesn't see the need to change a system that has resulted in remarkably few hacks or data breaches. The combination of security by obscurity and the fact that very few people have access to IBM mainframes tends to prevent exploits being developed. It looks like Young and Rikansrud would like to change that.
As was demonstrated in the presentation, it's quite possible to write, say, a buffer overflow exploit if you have access to an IBM mainframe. Mainframes systems were not designed to control malicious actors. The assumption was that if a company granted you access to a 3270 terminal attached to a mainframe you were a vetted and trusted employee. However, mainframes have evolved very good defenses against buggy code, and I suspect that it will prove to be quite difficult to come up with an exploit that could impact a production system.
The IBM Mainframe ecosystem has a bigger threat than hackers, though. The engineers who designed and implemented this architecture, the systems programmers who wrote the operating system, the applications programmers who wrote all the transaction processing systems that manage our financial transactions are mostly my age (sixty) or older. If they haven't retired already, they will within the next few years. The bright young systems engineers want to make their fortunes writing apps or social networks, not writing maintenance fixes to systems older than they are. Where is the next generation of talent to maintain the mainframes and mainframe systems we rely on going to come from?