* Posts by Arthur Coston

3 publicly visible posts • joined 3 Sep 2009

FreeBSD bug gives untrusted root access

Arthur Coston

BSD is good. OpenVMS better. All we can do now is preserve our past

Sorry, too long. Request of oldtimers.

In a typical day I probably use 10-15 different operating systems and HW architectures, have been doing this professionally for over 40 years. Today I have needed to use several flavors of MS Windows (always assume they are insecure and hacked), several BSD and Linux systems of various flavors (assume relatively secure, still wary and careful), routers and firewalls (very wary since they face the net), an iPhone (Apple overconfident, likely safer than alternatives), and OpenVMS (highly secure out-of-the-box, assume secure and safe against almost any attack short of stealing the machine and replacing some of its hardware),

Even with OpenVMS, as soon as you allow any type of executable or scripting you greatly increase your risk of being compromised somehow, though VMS makes it very difficult to escape beyond the initial user account. Almost all browsers are very insecure, even when we thinked they have been secured. While add-ins from Adobe, et al for Flash, PDF, etc. are among the most common attacked because of ActionScript, and while JavaScript is much the same, disabling these functions or using tools like FlashBlock or Noscript only affects the obvious issues; AV & FW product suites (e.g. Norton) help protect against additional attacks, but you are still vulnerable.

If there is ANY dynamic content, ANY executable component on the web page (e.g. XML, CSS, XHTML), ANY item included by reference (e.g. CSS, image) or implicitly (e.g. font), or ANY way to trigger substitution or chaining of URL/URIs, or ANY access to the environment/system beyond the current browser subwindow, or ANY possibility that an unsafe object will be "rendered" (e.g. XML/JS embedded in an image, maybe sneaking in as a color match or a playlist) -- if you allow anything beyond simple HTML implemented in lynx or w3m, you are can not be secure. Period. (BTW I am currently using w3m on Linux using a restricted account and posting this with the vi text editor.)

Finally, a couple of comments about what makes OpenVMS and a few other systems so much more secure than MS Windows, Linux, BSD, or any of the other Unix type systems, even when using additional security applications. By the time any of these opsys were designed, we knew a lot about to do and even more about what not to do if one was building systems with a reasonable level of security. DoD was a driving force and funding source for a lot of R&D projects (e.g. Multics) with many best practices reflected in the "Orange Book" and related documents.

These efforts plus the widespread use of timeshared systems and terminal networks in the 1960's and 1970's had exposed a majority of the problems still plaguing us today. We also knew how to mitigate and minimize these problems. So, what went wrong? How did we fail so badly as an industry?

A couple of basic issues, then and now, prevent widespread adoption of secure systems, and probably preclude anything ever being secure in the future. First, almost no one is willing to pay for security until it is too late; it is too late after the first insecure design decision. The gov/mil markets and a few others would pay for a while, but even they were eventually forced to use Commercial Off-the-Shelf (COS) for most applications, losing any prospect of secure systems. As a result, we have now have ships, planes, and critical national infrastructure controlled by systems using MS Windows running on hardware made in insecure foundries in India, Malaysia, China, or who knows where.

The second component was the rise of Unix and the C language at research and university sites. Unix, like the earliest computers of the 1950s and like the later PCs, was designed for a single user or a small number of trusted users with almost know regard to issues of security. Very simple versions off root/user (all privs vs limited) were included mostly to protect the user from himself, possibly the next user. and maybe a hardware failure.

They also implemented almost no validation of arguments in calls for system services; if you crashed the system, you were the one hurt, fixed the problem, and tried to be more careful next time. Even worse, the C programming language lacks even the most basic features required for any useful application: character strings, I/O, error checking and handling. Sure, with enough skill, care, and time almost anything is possible -- but not for most people most of the time. Since most implementations of Unix/C library and system calls don't validate their arguments, particularly those zero-terminated strings and various pointers to data structures, then any chance of security is lost before you begin.

Unix/C became "hot" at many of the newly-founded computer science departments because if was "free" to universities from AT&T, it was somewhat portable and could run on relatively inexpensive hardware, and because it came with source code, allowing almost anyone with minimal training to immediately begin doing operating system R&D, something almost none of the new generation of CS professors had done, most lacking any work experience outside grad school and almost none knowing real-time, process control, or security.

So while the relatively small group of first (1950's) and second (1960's) gen programmers were using hard-earned lessons to design the HW/SW using best practices, our labors would eventually be supplanted by the much larger market fueled by lower price, quicker results (even if wrong), and unprepared to comprehend the problems and the true costs that would be paid. Workstation vendors (Sun, Apollo, HP, even part of DEC) were happy to push the merits of the Unix-based solutions versus the user being tied to any propietary system (happier to avoid the most of the SW development costs for opsys or compilers for COBOL, PL/I, FORTRAN). The Unix vendors seemed oblivious to the PC market using exactly the same low cost, commodity HW and SW arguments to destroy most of their markets, even using still worse quality software, poorly tested, badly designed, and barely useable. But it was cheaper and you could even do some things yourself. So what, if your spreadsheet was full of errors and the cross foots never matched.

What is really sad is that most of the arguments used by each successively gen of HW/SW against the previous one or two gens are mostly lies. For example, OpenVMS sources were always available, though most only got the microfiche; OpenVMS as portable enough that versions for three radically different HW designs were sold commercially; OpenVMS was one of the first systems certified as meeting the "UNIX"/OSF standards; while initial cost of OpenVMS systems was higher than comparable UNIX systems, most of this was artificial in failed attemps at market segmentation and operational costs were much lower than similar UNIX or Windows systems (I think the number of people required were 3 and 10 times more), and most of the innovations in Unix/Linux/Win desktops and systems (e.g. I18N, clusters, transactions, file system, remote desktop) had been in OpenVMS for many years. Better technology rarely beats lower price, aggressive marketing, and the next generation of trendy users.

At this point, I am not really bitter about how things turned out in the industry, it was probably more-or-less how the world now works. I do get frustrated when I have to spend several hours trying to isolate the cause of a functional or security issue, only to find it caused by a design that should never been allowed in the first place. First rule of automation, "Does this really need to be automated (computerized)?", alternate version "Why does this need a web interface?". By default, the answer should be an emphatic NO!

I worry when I look at my customers, their applications, and the prospects in the future when I and others with critical KB are no longer available. Some of their systems control critical infrastructure (power, water, financial transactions, oil and gas distribution, manufacturing, etc.), have been operational for 15-20 years, and might have planned operational lives even longer into the future. What will happen when we and other specialty suppliers are no longer around? We caught a small glimpse of this when dealing with the Y2K problem, but that was easier because there were still many with the technical and institutional knowledge still around.

We see this increasingly in many industries as revenue from new sales and support contracts eventually falls below the level needed to sustain a small business able to continue maintaining software and specialized data collections. Who will pay to support the archive of a web site or publication that has ceased operation? Who will respond the next time a hurricane destroys many of the oil platforms if those like us are no longer around?

I see it as a duty to make sure that my unique and extensive collection of HW/SW/docs is placed in the trust of an appropriate university entity as soon as possible since one never knows how much time remains. I had one 1950's system I thought safely stored be sold by the government for scrap metals and vowed never to allow that to happen again. As a result, I now have a significant collection to protect properly while I still can.

Some of you has similar responsibilities; think about what might be lost forever if you fail to document your unique knowledge of what really happened before about 1980, how things operated in "olden" days, and to ensure that all the programs and documentation from before PCs are preserved. I was recently surprised at how much effort was required to get a working IBM 1401 system and there were over 20,000 of them made. I was really happy when I was able to confirm that a 1403 printer could still play "Anchors Aweigh". That was by far the most widely used computer of its time, and it was still barely possible. Act before it's too late.

Sputnik, spaghetti and the IBM SPACE machine

Arthur Coston

Powers of 2 calculation on decimal machine (BCD)

On a decimal/BCD machine you aren't working with binary shifts. The 1401 had a multiply so they could have implemented it with a loop though there might have been some trick to it. On binary machines, powers of 10 might have an underlying multiply by 10 that was done by load orignal value, shiftLeft2, add original value, shiftLeft1

BTW When implementing binary floating point, this was my preferred method for squeezing out succesive decimal digits for printing from a binary fraction.

EBCDIC came along five years later with the 360.

The internet celebrates the Big Four-O

Arthur Coston

Large operational networks already existed in the real world

The DARPA work 40 years ago, while important, was just one of many networking projects, many having begun much earlier and were already in daily operation. Even the "packet switching" aspect was included in some of these already-existing systems. BBN, which implemented the IMPs, was one of many suppliers of timesharing and related networks. If I remember correctly, the initial IMPs were based on existing designs already in use for TS work.

For a personal example, forty years ago here in North Carolina, the TUCC network supported the three primary universities (UNC, Duke, NC State), IBM, several other businesses, and a total of 45 colleges around the state through the NCECS network. While some of these schools might have just remote card reader/printer sites and a few had little more than a few Teletype terminals, other locations had extensive computer-to-computer networks.

While most of the connections were typical of 1960's time-shared or batch operations, there were a number of specialized devices on these networks (e.g. CalComp plotters). In 1968, I added support for a bit-mapped graphics device (the CC-30) -- quite slow over a modem and not very good resolution either. (That was using BTAM on 2701 controller; in 1969-70 I did animations on a CC-30 channel-attached to a PDP-8.)

Read about timesharing (e.g. DTSS) and networks (e.g. Burroughs Poll-Select/Contention) and you might be surprised at what existed in the late 1960's. You might even find email and markup languages long before HTML.

So enjoy the "birthday", but keep it in perspective. Now you kids get off my lawn!