'joe' suffers from an exploitable stack-based buffer overflow in parsing the path to the current user's home directory.. Note that this is not critical, because joe does not run with elevated privileges by default. Reproducible: Always Steps to Reproduce: ulimit -c unlimited; HOME=`perl -e 'print "a"x1030; print "abcd"'` joe; echo q|gdb joe core Actual Results: note that the actual "buffer size" may vary from distribution to distribution.. 1034 is on my actual gentoo system with joe-3.0 compiled with - O3 and gcc 3.3.2.. if it does not work, try with 1056 or more I found this bug about three years ago and it seems that it's still unfixed.. Could someone (joe maintainer?) take a look at it? The actual vulnerable function is procrc (rc.c): s = (unsigned char *)getenv("HOME"); main.c: /* ... */ if (s) { s = vsncpy(NULL, 0, sz(s)); s = vsncpy(sv(s), sc("/.")); s = vsncpy(sv(s), sv(run)); s = vsncpy(sv(s), sc("rc")); c = procrc(cap, s); /* ... */ int procrc(CAP *cap, unsigned char *name) { /* ... */ unsigned char buf[1024]; /* Input buffer */ /* ... */ strcpy(buf, name); /* ... */ }
Confirmed (propolice will prevent this, however).
Created attachment 43935 [details, diff] Silly patch for buffer overflow
This is extremely unlikely to be a security vuln. But I added a stupid patch anyway. What else do I do on a lazy Sunday morning?
OK, I was going to reassign, but I had a collision with Jaervosz. In either case, definitely ``no'' on a GLSA for this, and personally, I wouldn't even consider it a security fix. But it's no big deal either eway.
I agree with Dan reassigning to tomk.
shouldn't it have been strncpy(buf, name, sizeof(buf)); instead of strncpy(buf, name, sizeof(buf) - 1); ?
Just to be on the safe side lets make it: strcpy(buf, name, sizeof(buf) - 1); buf[sizeof(buf)-1] = '\0'; Fixed, in CVS.
