Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for September 7, 2006Security 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:
For all system products which use vulnerable versions of the
kernel, Avaya recommends that customers restrict local and network
access to the server. This restriction should be enforced through
the use of physical security, firewalls, ACLs, VPNs, and other
generally-accepted networking practices until such time as an
update becomes available and can be installed
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.
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:
We are now officially starting parallel development of 2.6 and
3.0. I really don't expect that we'll be able to merge the easily
into the 3.0 branch much longer, so effectively 3.0 will be a fork
of 2.5.
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 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.
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:
"Companies worldwide are capitalizing on applications developed by
the Eclipse community, and many software vendors sell products that
are dependent on Eclipse," said Mike Milinkovich, executive
director of Eclipse Foundation. "For that reason, it is absolutely
vital for us to analyze our code before we release it to our
community."
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:
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.
Page editor: Jonathan Corbet Security AJAX and security Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a local application. Unfortunately, AJAX also provides a number of serious security issues that should be considered and, at least partly because the technique is relatively new, many of the tutorials and other documentation completely disregard the security implications. Developing secure code rarely gets the attention it deserves and new technologies are typically slow to develop 'best practices' and to disseminate that information throughout their community. This can only lead to exploits in the future. Traditional web applications are synchronous in nature, a user clicks a button or link which sends a request to the server; the server replies with a page of HTML and the browser displays the new page. AJAX applications do some amount of work in the background, making requests of the server, sometimes without explicit user input. These applications do not refresh the entire page as they receive replies from the server; they only modify parts of the page or their internal state which gives users a much smoother, less page oriented experience. One of the best known examples of an AJAX application is Google Maps. While the user is viewing a particular section of the map, the client requests other sections of the map that are not yet visible and this allows the user to seamlessly scroll the map to view off-screen sections. Auto-completion for text fields, automatically updating form elements and form submission without a page refresh are other common uses for AJAX in these 'Web 2.0' applications. In order to handle the asynchronous server requests, AJAX programs use the Javascript XmlHttpRequest (XHR) object. The name of this object is really where the X in AJAX comes from as XML is not necessarily used in the XHR request or response. A client sends a request to a specific URL on the same server as the original page and can receive any kind of reply from the server. These replies are often snippets of HTML, but can also be XML, Javascript Object Notation (JSON), image data or anything else that Javascript can process. Various queries and requests that were once handled internally on the server are now exposed as a de facto API for AJAX applications. This drastically increases the attack surface of these programs because there are so many additional ways to potentially inject malicious content. Filtering user input correctly is, as always, the single most important safeguard for a web application; this is an area that traditional web applications have regularly failed to handle correctly. It is difficult to see how adding additional ways to get user input into the application is going to help this problem. SQL injection and Cross-site scripting (XSS) are two attacks that can be made against an application that does not filter user input correctly. AJAX techniques allow for additional ways to exploit these vectors in the background, undetectable by the user. The Myspace samy worm (more technical description here) is an example of the kinds of things that can be done. At the recent Black Hat Briefings, there was a session describing a port sniffer written in Javascript that could potentially discover internal network details behind a firewall and report them to a malicious site. The requirement that XHR objects refer only to URLs on the same server is an excellent security choice. Unfortunately, it is probably the single biggest complaint that web designers have about AJAX. Because they often want to display information from various sources on the same page, the restriction is considered to be 'too strict' and to get around it, AJAX bridges came about. An AJAX bridge proxies requests to other servers, returning the remote server's response. This allows XHR objects to refer to URLs on the server that returned the page, but still retrieve content from other servers elsewhere in the web. Unfortunately, this can lead to various abuses. Depending on how it is written, the bridge can provide a means to attack the third party site via SQL injection or XSS and allow the malicious user to hide behind a level of indirection. Various monitoring tools could detect the attack and shut down access for the aggregating site, effectively causing a denial of service attack. By proxying requests, a site is implicitly trusting its users not to abuse the APIs of third parties. Many of these attacks are not new, nor do they require AJAX to function, but by incorporating AJAX techniques into web applications, they are made easier. At one time, it was considered reasonable to turn off Javascript for many or all sites, but with the prevalence of Web 2.0 applications, this just is not possible for most web users. Web application developers need to be vigilant in rooting out the bugs that allow these attacks to succeed.
New vulnerabilities capi4hylafax: missing input sanitizing
cheesetracker: buffer overflow
gcc: file overwrite vulnerability
ImageMagick: buffer overflows
kernel: denial of service
MySQL: denial of service
openssl: insufficient signature checking
openttd: denial of service
sendmail: denial of service
Updated vulnerabilities AlsaPlayer: multiple buffer overflows
apache: cross-site scripting
audacious: buffer overflow
binutils: buffer overflow
busybox: insecure password generation
bzip2: race condition and infinite loop
cpio: arbitrary code execution
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
mozilla: multiple vulnerabilities
freeradius: several vulnerabilities
freetype: integer overflows
gdm: improper file permissions
gtetrinet: buffer overflows
gzip: arbitrary command execution
ImageMagick: heap overflow vulnerability
kdelibs: kate backup file permission leak
kernel: denial of service by memory consumption
krb5: local privilege escalation
lesstif: libXm library privilege escalation
libgadu: memory alignment bug
libgd2: denial of service
libmms: buffer overflows
libmusicbrainz: buffer overflows
libpam-ldap: authentication bypass
libpng: buffer overflow
libtiff: buffer overflows
libtiff: buffer overflow
libvncserver: authentication bypass
libwmf: integer overflow
mutt: IMAP namespace buffer overflow
mysql: format string bug
MySQL: privilege violations
MySQL: logging bypass
ncompress: buffer underflow
openoffice.org: several vulnerabilities
php: arbitrary code execution
phpbb2: missing input sanitizing
phpbb2: multiple vulnerabilities
phpMyAdmin: multiple vulnerabilities
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||