RE: tcp/ip hardware offload

From: PIATT, BRET L (PB) (bp3847@sbc.com)
Date: 03/05/02 

From: "PIATT, BRET L (PB)" <bp3847@sbc.com>
To: "'Ron DuFresne'" <dufresne@winternet.com>, Richard Masoner <richardm@masoner.net>
Date: Tue, 5 Mar 2002 08:57:05 -0800

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This isn't just TCP/IP stack specific. I know for CPU thermal testing Intel
has some specific programs that will quickly heat the CPU up. I think most
of the motherboards today will shutdown the processor before it overheats
and damages itself though. These programs have been around for years and
hackers have yet to release a virus exploiting them. Until somebody
malicious makes use of programs like this or finds a way to DoS the TCP/IP
stack of one of these cards the vendors are going to ignore the cries of the
security community because it is too expensive to test for all these things.

Bret Piatt

- -----Original Message-----
From: Ron DuFresne [mailto:dufresne@winternet.com]
Sent: Wednesday, February 27, 2002 6:36 PM
To: Richard Masoner
Cc: vuln-dev@securityfocus.com
Subject: Re: tcp/ip hardware offload

Richard,

The closest discussion I've seen from time to time related to this, and
again recently on the firewalls list has been the hp printer cards and their
poor handling of simple variances in TCP params that send the printers they
are installed in into failure modes requireing a full recycle. The results
of simple nmap scans are known to either fully freeze up the printers or
send them into garbage page spewing moeds, yet they all require a recycle to
correct. Course, I have seen no mention of new hp direct cards with
corrected firmware released over the years, and this is an old known issue.
Perhaps the code to be used in the devices you mention is going to be much
more stable, but, you make a good point in that it's possible that future
exploits might well make such devices expensive door-stops of the future.
Hopefully the design folks are throughly testing the stacks and exercising
them to discover their potential limit prior to production and marketing...

Thanks,

Ron DuFresne

On Tue, 26 Feb 2002, Richard Masoner wrote:

> I'd like to bring up for discussion a topic I don't think I've seen
> before
> -- that of possible vulnerabilities in networking code in hardware
> devices. Specifically, several vendors are developing network adapters
> with full TCP/IP offload in the hardware. These aren't just cards with a
> network stack in firmware; a lot of these actually have the protocol
> implemented in silicon.
>
> iReady <http://www.iready.com> is selling the "iChip," which is
> targeted for lower-end, embedded applications. Adaptec and Intel have
> announced gigabit network adapters with full protocol offload.
> Driving these products is the burgeoning market for network storage
> (iSCSI in particular), and the fact that OS protocol handling can
> gobble up over half of CPU cycles just to process the incoming network
> packets. If you offload protocol handling, you free the CPU for other
> tasks. From a performance perspective, it makes perfect sense.
>
> I'll write to these companies for additional details (and hope for a
> response), but my guess is that the protocol is implemented in some
> sort of programmable logic on an ASIC, and that these adapters will
> not be in-circuit upgradeable.
>
> The risk I see is the discovery of a vulnerability in these hard-wired
> "protocol accelerators." What if a malformed packet could throw these
> adapters into an undefined state? In a software TCP/IP stack, you just
> patch the operating system and life goes on. What do you do with
hardware
> that's discovered to be vulnerable to DoS attacks?
>
> Is there a history of hardware being vulnerable to online DoS attacks
> like this? Has anyone discussed this already?
>
> Regards,
>
> Richard Masoner
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D. Just don't touch anything.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBPIT4ml+IxmqPU329EQIxiACgvW/kdeoYMR9HgbNGzNA/PCDbOasAn3lC
+HjXme2mO90WdLSY5bQ5iBtj
=Hq6y
-----END PGP SIGNATURE-----

Relevant Pages

  • Re: Changing port numbers
    ... > ip port for protocol number. ... > stack of them put together, I think that if tcp/ip is enable the whole ... it is possible with Windows and most IP firewalls to block an IP ... TCP/IP refers to a fair number of other IP protocols besides ...
    (microsoft.public.windows.server.security)
  • [PATCH x86 for review II] [14/39] x86_64: cleanup Doc/x86_64/ files
    ... Linux/x86-64 supports CPU hotplug now. ... Interrupt stack. ... This feature is called the Interrupt Stack Table ... Used for interrupt 12 - Stack Fault Exception. ...
    (Linux-Kernel)
  • Re: [git pull] core fixes
    ... > Suresh and I looked at the oops and looks like the root cause is in ... > - CPU B gets the call function interrupt and starts going through the ... > CPU A's stack, as that element is still in call_function_queue ... > - CPU B sees the wait flag and just clears the flag ...
    (Linux-Kernel)
  • Re: Opinions on complexity
    ... > it depends on what /kind/ of realism you expect out of it.) ... commercial implementacion of the TCP/IP, but a kind of simulation of it ... > from an established stack -- or at least budget two or ...
    (comp.lang.java.programmer)
  • Re: [PATCH] no need to check for NULL before calling kfree()-fs/ext2/
    ... >> that the return address be written to memory (the stack), ... > 1) On a modern cpu, a miss of the branch predictor is quite expensive. ... It can't be on machines that have a "call" instruction. ... That's what the advertising hype is all about. ...
    (Linux-Kernel)