A recent security advisory announced today by Rapid7 explains, "the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page). A working proof-of-concept root exploit is attached to this advisory." The advisory goes on to note that the FreeBSD and Solaris binary drivers are also likely vulnerable to the same flaw and cautions, "it is our opinion that NVIDIA's binary driver remains an unacceptable security risk based on the large numbers of reproducible, unfixed crashes that have been reported in public forums and bug databases."

Chad Loder [bio], Rapid7's Manager of Engineering, explained that NVIDIA has known about this bug in their binary driver for some time, "the link in the advisory is the earliest thread in which we could find an NVIDIA employee publicly acknowledging the bug, although it was reported back in 2004 and has probably existed even longer." Regarding the decision to announce the exploit to the public Chad explained, "I expect (or hope) that NVIDIA will fix the defect in their binary drivers quickly. I don't know anything about their development process or where their Linux drivers fit into their priority list. It seems that the majority of Linux users are perfectly willing to accept bugs in binary blob drivers from hardware vendors, so there is little incentive for NVIDIA to change their process."

A lengthy and interesting thread was started on the lkml by Chris Wright looking to define a centralized place to report security issues in the Linux Kernel. Chris offered his services in getting things set up, addressing his email to Linus Torvalds, Andrew Morton [interview], Alan Cox [interview] and Marcelo Tosatti [interview]. He explained that he wanted to centralize the information "to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure". The resulting discussion was joined by numerous members of the kernel hacking community, exposing a wide range of opinions.

Linus agreed that it sounded like a good idea, but qualified this by adding, "the _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with." An embargo in this case is the time period from when a security problem is first reported to when a fix can be made public. Marcelo pointed out that a certain amount of time is necessary, "for the vendors to catch up", explaining that "it is a simple matter of synchronization". Linus again stressed his dislike for the vendor-sec mailing list suggesting that at times the length of the embargo period is often more about politics than anything else. He then added, "but in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec)." In a followup comment he clarified, "btw, the only thing I care about is the embargo on the _fix_", noting that he was comfortable if there was a need to delay publishing an explanation of the security hole so long as the fix itself was quickly released.

A vulnerability in TCP, the transmission control protocol, recently received some exposure in the media. Paul Watson released a white paper titled Slipping In The window: TCP Reset Attacks at the 2004 CanSecWest conference, providing a much better understanding of the real-world risks of TCP reset attacks.

To better understand the reality of this threat, KernelTrap spoke with Theo de Raadt [interview], the creator of OpenBSD, an operating system which among other goals proactively focuses on security. In this article, we aim to provide some background into the workings of TCP, and then to build upon this foundation to understand how resets attacks work.

This is the first article in a two part series. The second article will look into how TCP stacks can be hardened to defend against such attacks. Toward this goal, we spoke with members of the OpenBSD team to learn what they have done so far, and what further plans they have to minimize the impact of reset attacks.