LWN.net Weekly Edition for September 7, 2006

Security updates for embedded systems

The Avaya S8500 Media Server is a product which "allows for a distributed enterprise over an IP infrastructure in the mid-market space (up to 3200 ports)." Whatever that means. It fits in a 1U rack space; it also, as it happens, runs Linux - Red Hat Enterprise Linux, in particular. So, when Red Hat recently produced a security update for its kernel, Avaya sent out an advisory of its own. As it turns out, however, Avaya has classified this set of vulnerabilities as being of "low" concern, so, by the company's posted policy, there will be no software update coming anytime soon. Instead, the fixes will be packaged up with the next regular operating system update.

In the mean time, however, Avaya has a helpful suggestion:

Restricting network access will certainly make a network server product more secure, but it might just interfere with the tasks said server was purchased to perform in the first place.

In a separate episode, your editor was recently wandering around on the net in search of a fix for some obnoxious behavior exhibited by his DSL router. As it turns out, this router runs Linux. One can telnet into it and wander around. It's always amusing to discover that one is running even more Linux systems than had been previously thought. This one is built upon a MontaVista distribution, and is running a 2.4.17 kernel.

As LWN readers may have noticed, there have been a few security issues discovered in the 2.4 kernel after 2.4.17 was released. Quite a few. The support services sold by MontaVista to its customers must certainly include security updates, but there does not appear to be any mechanism for getting those updates through to the end customers who will actually be running vulnerable software. That is true even in your editor's case, where the router was obtained directly from the local huge telecom company, which should have good records regarding the equipment at its customers' homes. Said large telecom company tends to be held in rather low esteem by its customers, but, even so, one might expect that it would make a minimal attempt to keep those customers (who are, in the end, connected to its network) secure.

The end result is that your editor's DSL router - a Linux system with all the power BusyBox can deliver - almost certainly contains known security holes. It has writable flash storage, and can run programs uploaded to it. This is a rather discouraging situation when one considers that, for many users, this router will be the front gate to their home or small business network. The potential for mass mayhem is real.

In both cases, we are seeing situations where Linux systems have been deployed into security-relevant roles, but the security update mechanism has not kept up with them. As Linux pushes its way into more low-end consumer-grade devices, this problem will multiply. Who thinks about applying security updates to their telephone? And which manufacturers of cheap consumer electronics will concern themselves with pushing security updates to their customers?

Linux systems can be quite secure, especially when they are pared down to a minimal set of functions. But one of the things that keeps Linux secure is the quick closing of known security holes, and the quick dissemination of those fixes to deployed Linux systems. Without that support structure in place, Linux systems (like all others) become vulnerable to holes discovered after they were built.

Embedded systems tend to lack that support structure. When the system is, say, a music player with no connection to the wider world, there is no particular cause for concern. Network-connected devices, however, are subject to attack. Fortunately, network-connected devices should also be able to detect and install security updates - though setting up such a mechanism in a way which does not create privacy concerns can be a challenge. It should be a solvable problem.

The use of Linux in embedded systems is a cool thing - especially if those systems are designed to allow improvements by their users. It is one more step toward World Domination. But that cause could be set back significantly by a single Linux-based router or cellphone worm. We do not yet know how to create systems which will remain secure indefinitely into the future. Until that problem is solved, we must maintain structures which can close vulnerabilities as they are discovered. Purveyors of embedded systems ignore that need at their peril.

Comments (31 posted)

Various notes, all about Python

Dave Jones's How user space sucks talk at OLS this year received quite a bit of attention. It is simultaneously discouraging and encouraging to know that so many of our applications behave as inefficiently as they do. Discouraging because we should be doing better than that; encouraging because there are obviously easy fixes to be made.

Jeff Waugh recently brought back memories of that talk with a weblog entry on how Python behaves. For the curious: start up an interactive Python interpreter, then examine it from another window with strace. That Python interpreter, seemingly doing nothing, is, in fact, busily waking up ten times per second so that it can do nothing in a more active way. The offending code (in the readline library) is easy to find; it wakes up every 100ms just in case somebody might have registered a hook to look for events outside of the input file descriptor. As it turns out, the Python GTK library does the same thing so that it can check for pending signals.

So a system running a number of Python GTK applications (and some systems have many) will be experiencing the load of each one of them doing nothing every 100ms. This sort of behavior uses CPU time needlessly and it keeps the processor from sleeping - thus draining laptop batteries more quickly. Not good behavior - and a bit of low-hanging fruit that, one hopes will get fixed in the near future.

Meanwhile, the Python developers are working toward a major new release with the first Python 2.5 release candidate in testing for the last few weeks. For a full description of what's in Python 2.5, see A.M. Kuchling's excellent summary. New language features include conditional expressions (something like the "? :" notation used in C, but with a very different syntax), partial function application (forms of functions with some of the arguments supplied ahead of time), a number of exception handling improvements, a "with" statement intended to provide robust cleanup handling, and a number of performance improvements. There is also a long list of new modules and enhancements to existing modules.

The Python developers have long talked, often not entirely seriously, about "Python 3000," the upcoming major update to the language. While the Python language has evolved considerably over the 2.x series, it has done so in a compatible manner - older Python programs continue to run (though Python extensions written in other languages have tended to break). With Python 3000, the plan is that anything can happen, and there will be no guarantee (or even, perhaps, hope) that unmodified Python 2.x programs will work.

Python 3000 has been, as they say, Py in the sky for some time. But it looks like that situation might change before too long; some serious plans for the Python 3000 series have been laid down, and development may happen soon. Very soon, according to Python benevolent dictator for life Guido van Rossum:

He goes on to suggest that much of the work for Python 2.6 may be oriented toward helping programs (and programmers) make the jump to the eventual 3000 release. So Python 2.6 may not contain a whole lot of new features, but it could have a bunch of new warnings for things that will break in the future - and fixes to the standard modules to avoid those warnings.

The first alpha Python 3000 release is expected sometime next year; it could be a year or so after that before the stable release (to be Python 3.0) is ready. Current plans are to continue to develop and support 2.x for some time - well into the 3.x series.

What will be in Python 3000 3.0? Python Enhancement Proposal 3100 has the details, as they are understood at the moment. These include the removal of old-style classes, various expression syntax changes, a new set syntax, use of Unicode throughout (but no non-ASCII characters used in the language itself), and much more.

Python hackers who are concerned about changes to the language might want to take a look at PEP 3099, a document listing the things that will not change. These include no implicit self, no programmable syntax, no overly complex parser, and so on. There will be no braces added in Python 3.0, preserving the grouping by indentation that is such a strong characteristic of the language; for some amusement, fire up Python and type:

    from __future__ import braces

In the end, for all its changes, the Python language will still be very much true to its original goals: a straightforward language with one clear way to carry out most tasks. Python 3.0 will also be developed in an evolutionary manner - no massive rewrite or multi-year series of pronouncements from the language designer. As a result, Python 3.0 should, despite its rather later start, be in use well before Perl 6.

Finally, for a different and interesting project, PyPy is worth a look. These developers are writing an entirely new Python interpreter - in Python. There are a lot of goals driving this work, one of which is the ability to compile the interpreter into a runtime system which is highly targeted for its intended purpose. Different builds can use different memory management algorithms, for example. The developers believe that they will eventually be able to build Python systems which run faster than the current C interpreter - though, at this point, they are running about three times slower. It is an active project, however, which is making rapid progress; expect interesting things from that direction.

Comments (21 posted)

Eclipse signs up Black Duck

Black Duck Software was profiled on LWN by Pamela Jones just over one year ago. This company sells a product which enables companies to verify the sources of software in products that they ship; in particular, it seems oriented toward helping proprietary software vendors avoid unwitting violation of licenses like the GPL. This product includes "code prints" of thousands of free software releases; these prints can be compared against a program to determine if any of that program's code came from one of those projects. It seems like a product which could bring some peace of mind to company managers who worry about whether their programmers might be using free code in projects which are not intended for free release.

Whether the database of code prints (much of which is obtained through a "special relationship" with SourceForge) constitutes a derived product from the free software code it is "compiled" from is an interesting question - but one for a different article.

Today's topic involves this Black Duck press release stating that the Eclipse project has purchased Black Duck's "protexIP" product to verify licenses in the Eclipse code base. From the PR:

At first blush, it might seem a little strange that a free software project would purchase a proprietary tool to help ensure that no free code is incorporated by mistake. There are, however, a couple of reasons why Eclipse might want to take this step:

• Eclipse is distributed under the Eclipse Public License. It is a free license, with copyleft-type requirements, but it is not a GPL-compatible license. So the incorporation of any GPL-licensed code into Eclipse would be a bad idea.

• Black Duck has been expanding its database with thousands of "code prints" claimed from proprietary programs. Thus, the product should be able to detect attempts to use proprietary code in cases where that code has been fingerprinted by Black Duck.

So, if there are people within Eclipse who are worried about those types of code contamination, perhaps using Black Duck's products will help them to sleep a bit better at night.

One wonders, however, about what sort of commercial pressures might have pushed Eclipse to make this decision. While Black Duck would, beyond doubt, like to see this adoption as the beginning of a trend in the free software world, some of us may feel a little differently. It would be a sad day if we came to the point that free software projects had to buy this sort of service to be taken seriously in the commercial world. Releasing software is a remarkably easy process - at least, for those of us who are not under the control of large corporate legal departments. Loading up the process with expensive validation bureaucracy in the name of license compliance seems like a step in the wrong direction.

Comments (3 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: AJAX and security; New vulnerabilities in gcc, the kernel, MySQL, openssl, sendmail, ...
• Kernel: Drivers in user space; Parallel IDE drivers; Guest page hinting.
• Distributions: Debian's Alioth cracked; new releases from Ubuntu, Slackware, Debian, 64 Studio, CentOS and Morphix
• Development: A look at the Firefox 2 Beta 2 browser, Gnome 2.17 schedule, KOffice summer of code projects, new versions of MySQL, Samba, Archiveopteryx, bogofilter, gEDA, GNOME, Linux Libertine, XML Schemas, Unicode 5.0.
• Press: Politics of open-source in education, GNOME 2.16 review, GPLv3 Conference report, MySQL to drop Berkeley DB, Forbes looks at Ubuntu, Wind River report, SanDisk MP3 license dispute, Australian DMCA, lots of interviews, IDC on open-source, Collax takes on MS Small Business Server, FSF reaches out.
• Announcements: EFF on RFID, 10 years of KDE, X.Org board nominations, Sun Studio Express launched, Richard Stallman at GPLv3 conf, DTL meeting on fonts and Linux, IT Underground, Warsaw cfp, PyCon 2007 cfp, Ohio LinuxFest 2006, software tagging workshop, Software Development Best Practices India.
• Letters: Qmail; The new dependency hell.

Next page: Security>>