[Gllug] just preaching to the converted !

[Nix]

On Wed, 26 Oct 2005, Martin A. Brooks stipulated:
> On Tue, 2005-10-25 at 22:43 +0100, Nix wrote:
>> I don't see what testing (other than pen-testing) has to do with
>> security. Stability, sure. Security, no. No amount of testing can prove
>> a system secure.
> 
> You miss the point:  wide enough testing can prove the system to be
> insecure.

s/can/will/ :(

> Your compiled-from-source-firewall is vulnerable to security problems
> that the shipped-with-debian-firewall is not.  I'm not saying these
> problems will ever be found or exploited.  My point is that _you don't
> know what they are_.

... and *neither does anyone else* because they don't have access to
those binaries unless they've already successfully attacked the
firewall. The only way they can find such holes is by luck or by
assuming similarity to other known binaries --- i.e., by
inspecting the source and finding holes there.

This is the *one* case where security by obscurity is actually useful.

> On the other hand my bash binary, which is the same as the bash binary
> which is being used on thousands, if not hundreds of thousands, of other
> systems, has no known security problems. 

Security holes in a shell?! If someone has access to a shell then, um,
they can do anything the shell can do, which amounts to arbitrary code
execution as the effective user.

The very idea of a security hole in a general-purpose shell is
ridiculous. Such a hole couldn't grant more rights than any user of
the shell has anyway.

> So I have a choice, the debian binary which thousands of people are
> using and haven't found security issues with, or your binary which
> exactly one person has used and thinks is secure.  Guess which I'm going
> to use.

So, um, you're going to use a binary which every bad guy on the planet
can inspect and, should he find a hole, can hardwire fixed offsets into
his buffer overflows. Those fixed offsets *just won't work* on most
binaries built with different compilers, on different systems, et al.

(And, yes, plenty of shellcode has very particular assumptions about
allocation order of local variables, alignment, et al wired into it.
Change any of those and that shellcode will crash the process rather
than exploiting it. Anything which turns a crash into an exploit is
a good thing in my eyes.)


(The only way to break shellcode in identical binaries that I can think
of is randomly introduced perturbations built into the calling
convention and applied at runtime, but that would slow every function
call down and drain the entropy pool at fearsome speed.)


FWIW a couple of people have attacked my home systems with apparent
0-day exploits[1] and failed *precisely because of this*; the alignment
of functions wasn't what they expected because I compile everything with
-Os, so their shellcode crashed at once. (Of course if they'd got past
that they'd have run into ProPolice and the reversible virtual machine
and the alternative calling convention I'm using, but ignoring those...)


[1] well, in one case it was a 2-day exploit and I was sick in bed.
    What a time for an OpenSSH hole to come out, bah.

-- 
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
 I want. I am hoping for "Witnesses reported the sound up to two hundred
 kilometers away" or "Last body part finally located".' --- James Nicoll
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug