Bugzilla Bug 71129

'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 an attachment (id=43935) [edit]
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.