I discovered an off-by-one in siege. No upstream response/patch. Major info at $URL
Not reproducible. Your 'advisory' is lacking an actual bug description or a reproducer, are you able to provide any of these?
(In reply to Alex Legler from comment #1) > Not reproducible. Your 'advisory' is lacking an actual bug description or a > reproducer, are you able to provide any of these? You are not reading at all. > The issue is reproducible without passing any arguments to the binary. This looks to me to just type siege. Obviously you will *NEVER* see the issue if you don't une -fsanitize=address.
(In reply to Agostino Sarubbo from comment #2) > (In reply to Alex Legler from comment #1) > > Not reproducible. Your 'advisory' is lacking an actual bug description or a > > reproducer, are you able to provide any of these? > > You are not reading at all. > > > The issue is reproducible without passing any arguments to the binary. > > This looks to me to just type siege. Not here, no: % siege SIEGE 3.1.0 Usage: siege [options] siege [options] URL siege -g URL Given you (or your tools) have ascertained the configuration loading code to be responsible for the issue, I presume a certain configuration file would cause this (this is what I referred to as 'reproducer'). > Obviously you will *NEVER* see the issue if you don't une -fsanitize=address. ? Your article states 'I hit a segmentation fault.' I would have at least expected that to happen as well.
ok, let me explain better. 1) I hit a segfault using siege. 2) I recompiled it with asan 3) RUnning siege I see the off by one So, the segfault pushed me to recompile with asan which showed another bug, different from my segfault which is pending from be investigated. I hope is more clear now. To reproduce the issue you need to try: FEATURES="splitdebug" CFLAGS="-O2 -g3 -fno-stack-protector -fsanitize=address" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,lazy -fsanitize=address" emerge siege This is exactly how I compiled siege but you maybe avoid some flags like fno-stack-protector.
Okay here's what's happening here: 1. optionptr = option = xstrdup(line); 2. while (*optionptr && !ISSPACE((int)*optionptr) && !ISSEPARATOR(*optionptr)) { 3. optionptr++; 4. } 5. *optionptr++=0; 6. while (ISSPACE((int)*optionptr) || ISSEPARATOR(*optionptr)) { 7. optionptr++; 8. } Line 1, we copy `line` into `optionptr` using strdup, which is heap allocated. Line 2, is a loop that runs until we reach a non-space, a non-separator, or the end of the string (a null). Assume it reaches the end of the string. At this point, the loop ends, and `optionptr` is pointing to the null byte at the end of the string. Line 5, the null byte at the end of the string is set to null again (does nothing), and then `optionptr` is incremented to one past the end of the string. Line 6, `optionptr` is dereferenced to check its value, except this time it's pointing to an out of bounds value, resulting in Ago's "#0 0x51ab63 in load_conf /var/tmp/portage/app-benchmarks/siege-3.1.0/work/siege-3.1.0/src/init.c:263:12". The processing continues from this point, and depending on the layout of the heap, it could get a bit ugly. So, okay, off the bat, this is a programming bug. I don't really want to read this whole function to determine whether or not this bug could be used for any sort of code execution. Maybe it is possible; probably it isn't possible. In either case, is this really a security issue? Is siege a SUID program? Is it invoked by root on behalf of other users or using user supplied data? In what context does it run?
(In reply to Jason A. Donenfeld from comment #5) > Okay here's what's happening here: .. > In either case, is this really a security issue? Is siege a SUID program? Is > it invoked by root on behalf of other users or using user supplied data? In > what context does it run? My understanding is that it isn't crossing any security boundires. The application runs as user, and the config file is user-supplied.
This should be reported to upstream then
