segfaults due to mem corruption

[rofl0r]

on every run after a while on a musl-libc-based system(for example alpine linux). it's probably use-after-free, double-free, oslt.

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 21736]
free (p=0x646580) at src/malloc/malloc.c:474
474             if (next->psize != self->csize) a_crash();
(gdb) bt
#0  free (p=0x646580) at src/malloc/malloc.c:474
#1  0x00000000004026fe in queue_rem (s=0x614cc0)
    at /src/build/dirbuster-ng/dirbuster-ng-0c34920e2ae35c75e23eb271926e54ccc8c2bbad/src/queue.c:56
#2  0x0000000000401e15 in dbng_engine (queue_arg=0x614cc0)
    at /src/build/dirbuster-ng/dirbuster-ng-0c34920e2ae35c75e23eb271926e54ccc8c2bbad/src/dirbuster-ng.c:137
#3  0x00007ffff7dc38c0 in start (p=0x7ffff7fb4ae8)
    at src/thread/pthread_create.c:145
#4  0x00007ffff7dc5786 in __clone () at src/thread/x86_64/clone.s:21
Backtrace stopped: frame did not save the PC

issue can probably easily found with valgrind on a glibc-based system, however i cannot run it myself because i'm on sabotage linux with musl (valgrind uses a lot of glibc-specific hooks).

[mzpqnxow]

When I compile with debug information and run in gdb, it of course doesn't crash.. I suppose that's a workaround :>

Curiously, it does crash under strace...

[rofl0r]

honestly this program here is such a PoS that any minute on it is a complete waste of time. it should be rewritten from scratch by someone who knows what he's doing, and it won't take longer than a weekend to complete.

[mzpqnxow]

Yes, it's a fairly small effort to rewrite but at this point it would probably best be done in golang which will handle concurrency related complications for you. It also has some more friendly data structures like maps and such.

There are a lot of simple options that would a long way in making this much more useful as well (i.e. adding POST support, specifying what HTTP codes to look for as opposed to just 200, setting Content-Type on POST as well as having pre-set "mobile" user agents that might trigger different code paths... etc. I agree, it's not a gargantuan effort. But there aren't many fast directory brute forcing tools out there that are no frills that I am aware of that are multi threaded and provide native code performance with few to no external dependencies.

I suppose I will write one if I find the time or maybe you know of one.. I just tend to need a tool like this in a pinch and I'm sick of using bash while loops and curl :P

EDIT: and of course golang is memory safe, soo.... no more SIGSEGV

[rofl0r]

well... go may be a nice and productive language, but its not super portable. bootstrapping it on a system where there's no existing go compiler is pretty annoying, not to say a PiTA. it's not as bad as for example GHC or rust, but bad enuff. so since this is a mini project, i'd personally would write it either in C, or in C++ for the sake of having lists ("vectors") built-in. actually the reason why i considered using dirbuster-ng instead of the original one, is that the original is written in JAVA. (i still dont have java properly bootstrapped for my distro based on musl libc, sabotage linux, and go support is still in the first stages, requiring a bootstrap from go 1.3 to 1.4)

[mzpqnxow]

Yeah but you can build statically compiled exes for any of the major architectures and operating systems from one go installation just by setting environment flags. Producing Linux x86_64 exes from windows x86 golang is pretty damn cool fir a standard feature. It in effect has a built in cross compiler and a statically linkable libc. BTW I'm a huge fan of musl, I noticed we've both forked some musl stuff.

I agree though that installing the latest golang more than ever once is a pain but it is only a few steps- untar binary distribution, set a few environment vars, and you're done. I feel obligated to admit I just don't like C++ btw..

So If you're building your go from source, then I agree about it being a pain, as any toolchain is except musl, perhaps. I tried it exactly once. But I know I don't build my native development toolchain to compile C code (except when doing weird embedded stuff, which is perhaps your use case, and then I'll be forced to agree with you, I think)

Anyway I started the off-topic stuff so I feel responsible for ending it.. we can agree to disagree (or somewhat disagree) amicably as fellow musl enthusiasts :>

On Sat, May 20, 2017 at 23:07 rofl0r notifications@github.com wrote:

well... go may be a nice and productive language, but its not super portable. bootstrapping it on a system where there's no existing go compiler is pretty annoying, not to say a PiTA. it's not as bad as for example GHC or rust, but bad enuff. so since this is a mini project, i'd personally would write it either in C, or in C++ for the sake of having lists ("vectors") built-in. actually the reason why i considered using dirbuster-ng instead of the original one, is that the original is written in JAVA. (i still dont have java properly bootstrapped for my distro based on musl libc, sabotage linux https://github.com/sabotage-linux/sabotage, and go support is still in the first stages, requiring a bootstrap from go 1.3 to 1.4)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/digination/dirbuster-ng/issues/3#issuecomment-302912006, or mute the thread https://github.com/notifications/unsubscribe-auth/AHpRZBvlTPP8RgkRTKdWl6oEkwfRdE3Hks5r76pygaJpZM4LvVYX .