By Jake Edge
May 28, 2008
When considering the vulnerabilities of a system, the hardware is usually
ignored. Software certainly presents the biggest target—fairly easily
exploited as we have seen—but a new class of attacks goes directly at
the hardware, specifically network cards. The results can range from a
permanent denial-of-service to a complete compromise of the card's
function.
One researcher has overly cutely dubbed this kind of attack "phlashing"
because it attacks the firmware on the card, which is typically stored in
flash. The basic idea is that an attacker will rewrite the firmware using
an image under their control. That image could do any number of fairly
nasty things to the card.
Two separate researchers have recently reported on their explorations into this
type of attack. Arrigo Triulzi's posting to the, evidently private, Robust
Open Source mailing list was reported
on Ben Laurie's weblog. Rich Smith of HP also gave a talk on
his PhlashDance fuzzing tool at the EuSecWest conference. In both
cases, network devices were compromised via insecure remote firmware update
capabilities.
Smith's research focuses on causing permanent denial-of-service through
overwriting the firmware, presumably with garbage. At that point, the card
will no longer function and may, in fact, no longer be able to be
updated—remotely or locally—which turns it into a paperweight.
More importantly, no network traffic can use the device, so if it is
situated in a critical router, for example, it could affect a large number
of systems.
A more insidious attack is described by Triulzi. He replaces the firmware
with new code, effectively reprogramming the device to do whatever he
wants. One of the attacks goes like this:
[...] I've reached my goal of writing a totally transparent firewall bypass
engine for those firewalls which are PC-based: you simply overwrite the
firmware in both NICs and then perform PCI-to-PCI transfers between the two
cards for suitably formatted IP packets (modern NICs have IP "offload
engines" in hardware and therefore can trigger on incoming and outgoing
packets). The resulting "Jedi Packet Trick" (sorry, couldn't resist) fools,
amongst others, CheckPoint FW-1, Linux-based Strongwall, etc. This is of
course obvious as none of them check PCI-to-PCI transfers.
An additional trick, noted by Laurie and others is to use those same
techniques to read or write the main memory of the host computer. This
could certainly allow sensitive information to leak—or the host
itself to
be
compromised. As Laurie says: "You might even be able to read
disk, too, depending on the disk controller."
This is truly frightening stuff that is flying under the radar of most
network administrators. There are no known attacks in the wild, but it
would seem only a matter of time before that happens. This is definitely
something to keep an eye on.
Other than avoiding vulnerable network hardware—lists of which do not
seem to be available from either researcher—there doesn't seem to be
much that can be done to deal with phlashing attacks. A properly
programmed I/O memory
management unit (IOMMU) might alleviate some of the worst cases by
disallowing DMA outside of approved ranges, but card vendors need to make
updates more difficult. It might be more convenient for an administrator
of a large network to update multiple cards across the wire, but the price
paid for that convenience seems too high.
Comments (13 posted)
Brief items
The Open Source Software Security community (
oss-security) has announced
its existence. "
This project is an ongoing effort to manage security
information in Open Source software by building on the collaborative
foundation of the open source model. The purpose of oss-security is to
encourage public discussion of security flaws, concepts, and practices in
the open source community."
Full Story (comments: 2)
New vulnerabilities
emacs: code execution
| Package(s): | emacs |
CVE #(s): | CVE-2008-2142
|
| Created: | May 28, 2008 |
Updated: | February 24, 2009 |
| Description: |
The emacs editor will automatically load .fld files associated with other files and execute their contents. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2008-2137
|
| Created: | May 28, 2008 |
Updated: | July 16, 2008 |
| Description: |
The Linux kernel (SPARC architecture only) suffers from a denial of service vulnerability related to "issues with the virtual address range checking of mmaped regions." |
| Alerts: |
|
Comments (none posted)
mtr: stack-based buffer overflow
| Package(s): | mtr |
CVE #(s): | CVE-2008-2357
|
| Created: | May 23, 2008 |
Updated: | August 21, 2008 |
| Description: |
From the CVE entry: Stack-based buffer overflow in the split_redraw function in split.c in mtr before 0.73, when invoked with the -p (aka --split) option, allows remote attackers to execute arbitrary code via a crafted DNS PTR record. NOTE: it could be argued that this is a vulnerability in the ns_name_ntop function in resolv/ns_name.c in glibc and the proper fix should be in glibc; if so, then this should not be treated as a vulnerability in mtr. |
| Alerts: |
|
Comments (none posted)
php libcurl: safe_mode bypass
| Package(s): | php |
CVE #(s): | CVE-2006-4483
CVE-2007-4850
|
| Created: | May 28, 2008 |
Updated: | March 6, 2009 |
| Description: |
The PHP libcurl library (prior to 5.1.5) contains two vulnerabilities which enable an attacker to bypass safe mode, access arbitrary files, and, perhaps, execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
roundup: permission bypass
| Package(s): | roundup |
CVE #(s): | CVE-2008-1475
|
| Created: | May 28, 2008 |
Updated: | November 19, 2008 |
| Description: |
The xml-rpc server in the roundup issue tracker does not properly check property permissions, enabling those permissions to be bypassed. |
| Alerts: |
|
Comments (none posted)
samba: buffer overflow
| Package(s): | samba |
CVE #(s): | CVE-2008-1105
|
| Created: | May 28, 2008 |
Updated: | January 8, 2009 |
| Description: |
Samba (versions 3.0.0 through 3.0.29) suffers from a buffer overflow which can affect both server and client implementations; see this advisory for details. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>