I think we had to change this code when bringing up the Mavericks
buildslave. (http://gerrit.openafs.org/#change,10731)
So, it should be fixed for the next release already; the only question is
whether there would be security implications.
-Ben
On Mon, 21 Apr 2014, D Brashear wrote:
data off the wire never makes it there, so there should be no privilege
escalation. you may be able to crash something you ran yourself.
we'll check it out, though. still not good, just not likely to have
security implications.
and the krb5 options changes in configure. that page needs a refresh
On Mon, Apr 21, 2014 at 11:12 AM, Frederick Luehring
<luehr...@indiana.edu>wrote:
Hi Everyone,
Since there has been certain amount of excitement about the
consequences
of buffer overflows in recent days, I would like to point a possible
problem I
discovered when following the instructions to compile open afs on Mac OS
X. I
guess you know of this but just in case, if follow the instructions at:
http://www.openafs.org/macos.html
it sets the enable-checking flag which almost immediately finds:
gcc -Os -I/Users/luehring/openafs-1.6.6/src/config
-I/Users/luehring/openafs-1.6.6/include -I. -I. -Os -Wall
-Wstrict-prototypes -Wold-style-definition -Wpointer-arith -Wall
-Wstrict-prototypes -Wold-style-definition -Werror
-fdiagnostics-show-option
-Wpointer-arith -arch i386 -arch x86_64 -c cmd.c
cmd.c:46:30: error: the value of the size argument in 'strncat' is too
large,
might lead to a buffer overflow [-Werror,-Wstrncat-size]
strncat(tbuffer, a2, sizeof(tbuffer));
^~~~~~~~~~~~~~~
cmd.c:46:30: note: change the argument to be the free space in the
destination
buffer minus the terminating null byte
strncat(tbuffer, a2, sizeof(tbuffer));
^~~~~~~~~~~~~~~
sizeof(tbuffer) - strlen(tbuffer) - 1
1 error generated.
make[3]: *** [cmd.o] Error 1
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
