Re: Shimomura on BPF, NSA and Crypto

Tsutomu says the NSA is inept rather than inherently evil.  I think he
concluded this because they declined to fund his work.  An ept and
evil NSA would want Tsutomu on the payroll.

Tsutomu's stealth version of the Berkeley packet filter did a lot more
than modload into the kernel.  He was paid by the Air Force to design
one that could patch itself into SunOS kernels invisibly, even into
kernels with no modload support at all.  It had special code that
would search through the kernel binary for references to the address
of the Ethernet chip, and patch itself in during the very low level
interrupt handling.  It was highly optimized so it wouldn't show up by
loading down the machine, and it did things like decrement the
interrupt counter so that even the extra interrupts caused by running
the Ethernet chip in 'receive every packet on the wire' mode wouldn't
be visible.  He talked about enhancements that would automatically
forward packets of interest back out onto the Internet, so the whole
shebang would hide in kernel memory, never visible to users, never
running any processes or altering any files.  Think of it as Digital
Telephony wiretap technology for the Internet.

The idea was to design something that you could run on a machine
without the owner ever finding out about it.  To break into that
person's network.  It's a tool customized for crackers.  It's one
of the tools that Mitnick was after when he broke into Tsutomu's
machine.

Tsutomu actually wrote and ran this stealth BPF code (as well as
designing it) and got into a tiff with the Air Force.  They wanted the
code, not just the design paper they'd commissioned.  He countered by
offering to post the code to the net, with a copyright that let anyone
EXCEPT the government use it, if they wouldn't pay him for the paper.
I don't know how the situation was eventually resolved.

Tsutomu has lots of glib rhetoric about how he just builds tools and
they can be used for good or evil.  This tool is custom-designed for
evil.  Maybe in wartime the Air Force will want to inflict evil on an
opponent.  Or maybe instead they'll pass it to a latter-day J. Edgar
Hoover.  Either way, it's evil.  It doesn't become good when you
inflict it on someone you dislike.
-- 
John Gilmore                                    gnu@toad.com  --  gnu@eff.org
        Don't introduce that Tsutomu to your girlfriend.

>Tsutomu has lots of glib rhetoric about how he just builds tools and
>they can be used for good or evil.  This tool is custom-designed for
>evil.  

Rubbish, it would allow me to do something I urgently need to do - measure the 
performance of the main internet links. This is presently very difficult to do 
since the berkley sockets provide no network performance information to the 
application layer.

What I need is a means of determining the fragmentation, packet delay, 
throttling rate etc etc. This is information avaliable in the Kernel but I don't 
know how to get at it. The packet filters would provide a means to monitor, 
Tsutomu's kit would do the job better.

The reason why I need this type of stuff is that a number of governments are 
asking how many T3 lines they need to string across the ocean to get into the 
Internet game. If hard figures are avaliable they can make the case to fund 
them. [No Libertarian flames about government subsidy please, I'm not 
interested]

		Phill

hallam@w3.org writes:
> 
> >Tsutomu has lots of glib rhetoric about how he just builds tools and
> >they can be used for good or evil.  This tool is custom-designed for
> >evil.  
> 
> Rubbish, it would allow me to do something I urgently need to do -
> measure the performance of the main internet links. This is
> presently very difficult to do since the berkley sockets provide no
> network performance information to the application layer.

There is no need to have the code to provide such information conceal
the fact that it is on the machine, fake interrupt counts, etc.

> What I need is a means of determining the fragmentation, packet
> delay, throttling rate etc etc. This is information avaliable in the
> Kernel but I don't know how to get at it.

There are plenty of tools on the average unix box for asking such
questions, and all kernel variables can be read via /dev/kmem in any
case.

Perry

> >Tsutomu has lots of glib rhetoric about how he just builds tools and
> >they can be used for good or evil.  This tool is custom-designed for
> >evil.  
> 
> Rubbish, it would allow me to do something I urgently need to do - measure the 
> performance of the main internet links. This is presently very difficult to do 
> since the berkley sockets provide no network performance information to the 
> application layer.
[..]

The standard BPF does exactly what you want already. Can you say tcpdump?
I think some research is inorder before you go shooting off your mouth.

-- 
+----------------------------------+-----------------------------------------+
|Julian Assange                    | "if you think the United  States has    |
|FAX: +61-3-9819-9066              |  stood still, who built the largest     |
|EMAIL: proff@suburbia.net         |  shopping centre in the world?" - Nixon |
+----------------------------------+-----------------------------------------+