[Bug other/28328] Stack smash protection non-verbose

[nigelenki at comcast dot net]

------- Comment #8 from nigelenki at comcast dot net  2006-07-11 04:56 -------
(In reply to comment #6)
> (In reply to comment #4)
> >   Thank you, I see the problem, there's a patch attached.  Your distribution
> > should have a new version some time in a couple days.
> 
> Here is how normal GCC bugs go:

...

> attach the sound file you were trying to play.
...

But but!  I have 18,397 files in XMMS!  It was on another virtual desktop when
it crashed!  It was in shuffle mode!  I don't KNOW what file it was trying to
play and I can't get it to reproduce it!

Compilers are easy.  They die and say "holy crap I was trying to process this
and my tree did this and I failed to spill a register help!" and you go to the
bugzilla and go "It told me to give you this file it spit out" and go home.
(In reply to comment #5)

> John is mostly right in reporting this.
> 

...

> I would ignore the part in his comments about syslog() as running the 
> handler past that would mean that all vio/*intf functionality would
> have to have ssp disabled on it in *libc which pretty much means all of
> the libc.

Yeah, ignore that, it can be dealt with distro-side and I'll find another way
that's friendlier.  open and a named pipe, or a UNIX socket, or something.  The
handler's exact function can be altered without an API change.

(In reply to comment #7)
> (In reply to comment #5)
> > This bug should get itself assigned.
> 
> You know like many other open source projects, if you really want a feature you
> should implement it.

I'll try with 4.1.1 but I warn you I have no idea how gcc works internally. 
Gimme a little help if I get stuck?  :)

I'll poke the gcc ML if I get anywhere.  I guess I'll start by unit testing my
stack check fail function.

>  As I mentioned in the other bug, knowing where something
> crashed is only part of the story on debugging, you also need to know why,
> which can be much harder to see as the problem comes from 1000 lines before. 

Actually it won't come from 1000 lines before.  It'll go like this:

int vuln(char *s, int len) {
  char a[10];
  char b[20];

  a[0] = 0;
  strcpy(a, "str: ");
  strcat(a, s);
  return strlen(a);
}

Result:
*** stack smashing detected ***: vuln.c:vuln() (damage: 0xdeadbeef) /bin/vuln
Terminated

We know that we trashed a[] or b[].  Let's imagine there's 3000 other
functions, and figure out where to look... oh, in vuln.c in vuln().

> So getting this info is only useful for obvious bugs which someone could spot
> by going through the code line by line.

Of course you could write a test case for your code, if you know where your
code is breaking.

> 
> Also the user should not know your internals of your program, it just confuses
> them and in fact it might cause some of IP to be exposed and you don't want
> that.
> 

Confusing the user is a shoddy argument.  What's the alternative?  "Attempt to
reproduce it, even though you can't after 5 hours"?  "Run it through gdb,
because I can't reproduce it on my end"?  Trust me if you say to the user, "It
should spit out something like 'IP: 0x7b, SP: 0x99, stack dump: 00 77 de ad be
ef ca fe ba be', give me that," he'll go "uh... okay... don't know how you can
make any sense of any of that junk but..."

IP exposure is a shoddy argument, a static function name is not important and
an external function name is readable via readelf -s.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328