Jakob Bøhm Jensen (jbj@image.dk)
Thu, 23 Jul 1998 01:10:25 +0200
Secret details of the cfingerd version 1.3.2 buffer overrun bug.
This information should not be leaked to mailing lists, web pages
or other public areas until two months after a fix has been posted
or the program withdrawn from general use. In either case,
security alerts should be issued through all relevant channels to
ensure the fix is applied to all affected machines.
Please confirm this information independently before publishing
security alerts or doing anything else drastic.
I found 5 bugs:
1. in search.c, show_search() declares searchname as 80 characters,
but receives up to 100, minus the 7 chars in "search.".
2. in fakeuser.c, handle_fakeuser(80) does malloc(80), but may receive
up to 100, minus 2 chars in "x.", where x is a one character fake
user name (worst case).
3. in main.c main() does not check for buffer overrun when doing
strcpy(username, argv[2]); .
4. also in search.c, the searches array holds 500 entries, but no
check is made if this limit is exceeded, typically on an ISP system
with thousands of users. I have not tested this , but it should be
trivial to add a few thousand dummy users all called unnnn to
/etc/passwd just for the test (without bothering to create home
dirs etc.). Then finger search.u@localhost and watch the fireworks.
5. In util.c function parse_line(), when using the $EXEC feature,
the output from the script is read into a 160 character buffer,
with no protection whatsoever. This has not been tested either.
In general, it may pay to systematically comb the source code for
fixed buffers in parsing input, especially those that are 80 bytes.
Thus each of the following finger invocations will crash cfingerd,
given enough a's:
finger search.aaaaaaaaaaaaaaaaaaa....aaa@hostname
cfingerd -e search.aaaaaaaaaaaaaaaaaaa....aaa@hostname
finger uptime.aaaaaaaaaaaaaaaaaaa....aaa@hostname
cfingerd -e uptime.aaaaaaaaaaaaaaaaaaa....aaa@hostname
A fundamental design flaw in the setuid code in cfingerd means
that this occurs with a real user id of root.root and an effective
user id of nobody.nobody. Thus any root exploit would have to
directly or indirectly invoke seteuid, an act which does not
require any kind of password or other backdoor fiddling.
The setuid bug is reported separately.
-- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
This archive was generated by hypermail 2.0b3 on Sun Aug 08 1999 - 10:46:57 CEST