Mailinglist Archive: opensuse (4020 mails)

< Previous Next >
Re: [SLE] spyware
  • From: Anders Johansson <andjoh@xxxxxxxxxx>
  • Date: Mon, 4 Oct 2004 17:49:03 +0200
  • Message-id: <200410041749.03546.andjoh@xxxxxxxxxx>
On Mondayen den 4 October 2004 17.20, Örn Hansen wrote:
> måndag 04 oktober 2004 14:25 skrev Anders Johansson:
> > I'm not sure what you're saying here. It sounds like "it's more difficult
> > in windows, but it's more difficult in open source"
> What I'm saying is, very simple ... it's the question of "gun control".
> An old debate, on who is responsible. Well, in the gun control there's a
> saying that it's the man holding the gun, that is responsible for the
> damage made by the gun. Not the gun, by itself. However, some people wish
> to extend this to mean ... that if it isn't ME that actually pulls the
> trigger, than I am in the clear. Not true ... if I give a gun, to a person
> with significantly low intellect and then show him how to use it, and urge
> him to ... than I am, in fact, responsible for the damage made.
> To put this in the script kiddie case, the script kiddie is someone who
> doesn't have the knowledge of how to use it ... he gets the code, the info
> and the knowledge, and then he pulls the trigger. And I'm saying, you
> can't blame the script kiddie for his low intellect ... you can blame the
> employee that made the information available to him, for criminal
> neglegance.

In other words, since you refer to "employee", you firmly believe that it's
necessary to have access to the source code in order to create an exploit.
Well, that is simply wrong. You do need access to the binary so you can
determine the offsets required through trial and error (well, I think you do,
there may be cleverer methods), but you don't need the source.

> > It's a little more complicated than that. Google around for "heap
> > overflow".
> Actually, it's JUST as simple as that. Unless you are trying to tell me
> that there's a problem with how the memory controlling routines are
> implemented in linux. In which case, it's a serious ... yes, serious flaw
> in the linux kernel. And I'm well aware of some of the drawbacks on how
> i386 CPU's handle segments, but those drawbacks should have vanished a long
> long time ago, as far as I know as the segment should be handled by a true
> memory controller of all post pentium CPU's (again, as far as I know). The
> data allocated by a program, and the program code itself ... should not be
> within the same segment.

Nor do they have to be. Did you look around for some descriptions of heap
overflow exploits? It really is a little more complicated than you seem to
think. If it really were as simple as you put it, the world wouldn't be the
security mess it is.

In a sense it really is simple: just make sure no one can stuff more data into
variables than there is room for. If everyone did that, there wouldn't be any
overflow exploits regardless if it was on the stack or on the heap. The trick
is to get programmers to do that. That's where the language and tools
designers come in. Off-by-one errors and other buffer mishaps are oh so
simple to miss manually

< Previous Next >
Follow Ups