The default value for the X Aperture sysctl is now off. What's so evil in modern video cards?
Matthieu Herrb: Loic Duflot demonstrated in an excellent paper [PPT slides] at CanSecWest that the hardware access privileges that the X server is granted by the aperture driver can be abused to gain access to kernel privileges (allowing to bypass the security level settings for example).
The X server paradigm of "userland drivers" exposes all hardware features to userland. Some of these features (Loic used the Pentium System Management Mode, but there are probably dozen of other similar features for this purpose) can be used to bypass the memory protection and thus provide the X server with full control of the kernel.
OpenBSD developers went through the effort of privilege separating the X server as its own user, but it doesn't help at all for this issue. We've also tried to design a better protection scheme with the current X design, but it appears to be almost impossible. The X server needs to be redesigned to not require direct access to hardware.
We think it is a very urgent matter for true security will never be achieved otherwise. For the time being the only advice we could give to OpenBSD users who want their system to be secure is to keep
allowaperture=0 and not use the X server on those systems.
Also note that other systems have no protection at all against this attack.
I remember that just before releasing 3.8 you had to disable the new behavior of your implementation of
free() that returned SIGSEGV when accessing a freed area. You had to do this because too many ports were instable (crashing). Does 3.9 enable it by default?
Otto Moerbeek: I first have to make a correction: we do unmap unused memory, but not very aggressively. There are too many programs containing "use-after-free" bugs that would stop working if we unmapped unused memory all the time.
Apart from some code cleanup, the
malloc implementation did not change for 3.9; it has been proven to be very solid. Its stricter checking and randomizations features enabled us to find evil bugs in all kinds of software. And, of course, these mechanisms also provide extra protection against heap overflow bugs that could potentially be exploitable.
While many buffer write overflows have been solved in a lot of software, read beyond end of buffer bugs are still quite common. To be able to catch these as well as use-after-free bugs, we hope to make our
malloc even more strict in the future, but these steps have to be taken very carefully; if our
malloc becomes too strict -- even while staying within boundaries defined by POSIX -- too many programs and users will suffer. But if we do it right, in the end everybody will gain: bugs will be found and fixed.
What's new in
pkg_add and other
Marc Espie: A lot!
pkg_add -u (updates) now works. Specifically because
pkg_add can recover from most FTP errors now. And the full code was activated.
There is also an interactive mode,
-i, that you will want to turn on most of the time. Instead of aborting,
pkg_add will ask questions when it can't find the correct answer. This goes from simple things like:
pkg_add -i screen
asking you which screen package you want, to more complicated stuff, to making sure you want to perform potentially dangerous operations.
There is also Nikolay's work to let you grab packages through FTP, when available, instead of building them from the ports tree. You just have to set
FETCH_PACKAGES for that.
Aside from that, there have been hundreds of bug-fixes in fringe cases. The package tools cope much better with a wide variety of error conditions: if the md5 of installed files do not match,
pkg_delete will leave you with a stub package instead of simply reporting it did not remove the package.
pkg_add -u will update packages when they depend on stub library packages, instead of leaving them around.
pkg_add will refuse to install packages with INSTALL scripts if it finds you the relevant partition is mounted noexec, etc.
In short, we do think that package updates are ready for production uses. Most of the ports developers have been using it for months by now.
A new tool called
sdiff was introduced in the 3.9 release. Could you explain what it does and how it works?
sdiff is visual comparison tool that displays two files side-by-side, with differences marked. An interactive mode can be used to merge changes, prompting the user at each difference.
One use of
sdiff is to merge updates to configuration files. Configuration files are often customized for each machine. Over time, vendors add new options or change defaults in configuration files.
sdiff can pull in vendor updates while keeping local customizations.
This implementation of
sdiff is new, but
sdiff already exists on many Unix systems. In fact, there was an
sdiff in previous versions of OpenBSD, but was removed from OpenBSD when the GNU
diff utilities were replaced by BSD ones.
OpenBSD and OpenSSH have been in the news lately with an appeal for donations. Could you please describe what happened?
Ray Lai: The costs of producing OpenBSD have been increasing, while the income generated has been decreasing. The percentage of people choosing to download through FTP instead of buying CDs has increased dramatically. While the number of OpenBSD and OpenSSH users has been increasing, the total number of CD sales has been decreasing!
New hardware is always needed to improve support and to replace or upgrade the infrastructure. Due to cooling requirements and electrical consumption, running this new hardware increases the already monstrous electric bill, currently at $100 per week.
The project's growth is fueled by hackathons, yearly events where developers come together and code for a week straight. OpenBSD only pays for accommodation. Tickets and other travel expenses like food are paid by the developers themselves. OpenBSD tries to pay for the tickets of poorer developers, but has very limited resources to do so. Many new developments came from hackathons, including SMP support for AMD64, SSH tunneling, improved 802.11 wireless networking, and PF.
Hackathons have been so successful that mini-hackathons have taken place, concentrating on specific areas of OpenBSD, such as the ports tree or PF development. More of these are planned in the future, so please make it possible!
David Gwynne: I agree with Ray, the hackathons are important for the project because it speeds the whole process up. A lot of OpenBSD development relies on discussion between the developers which is usually done via email. For example, at last year's hackathon I remember pascoe and krw being annoyed by mjc with lots of SCSI/umass interaction issues. There were some real fixes in both layers that improved things that a lot of people were complaining about.
The hlt hlt bug was also found and fixed at the hackathon. I'm not sure it would have been found in any other environment. Because the developers were all in the same room the discussion was sped up. Email just can't compete with a face-to-face conversation. As a result, everyone's issues were raised and discussed in minutes rather than the hours it takes to get email back from people all over the world in a variety of time zones. I'm sure that the fix to the hlt hlt issue would have taken months without the hackathon. Instead it was fixed in a day.
The hackathons also give us an opportunity to really focus. [For example], marco did a lot of hard work on figuring out how to interact with ami hardware at the last hackathon. Without this foundation bioctl might still be in development. ;)
These are just a few examples that show how the hackathons are a good investment for the community.
Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.
Return to the BSD DevCenter.