Sun 02 Mar 2014 12:35:46 PM UTC, original submission:
gdomap, when told to run in daemon mode, calls openlog() early on in main() to initialize the system logger. Internally, openlog() (at least in (e)glibc) creates a fd to connect to the system logger via a unix domain socket.
gdomap, after command line parsing etc., and forking, then ensures that there are no open fds that may interfere with its operation by closing them all (skipping stderr). Unfortunately, this also closes the fd that openlog() just made. Eventually, this closed fd's number is re-used for gdomap's UDP listening socket.
The net effect is: when a call to syslog() is later attempted, syslog()'s attempt to send to the system logger fails. It then closes what it thinks is still its fd (but is actually now the UDP listening socket mentioned above), and attempts to reconnect to the system logger. (For whatever reason this fails.) gdomap eventually notices in its handle_io() loop that the UDP listening socket is closed, and dies with the message "Fatal error on socket." (trying to syslog it, funnily enough).
This was found by sending an invalid message to a gdomap daemon via TCP (triggering the "Illegal operation code received!" message) and observing gdomap dying instead of continuing on gracefully:
$ sudo gdomap
$ pidof gdomap
23357
$ ( echo -ne "AA\x12AAAAA"; head -c256 /dev/zero ) | nc localhost gdomap
$ pidof gdomap
$
I think I read in the mail thread about Dan Rosenberg's gdomap CVE-worthy bugs that gdomap isn't a crucial part of GNUstep anymore, but I thought this would be still worth reporting. (If it is still a useful part, I would consider this a low-severity security bug since it's a simple DoS that can be triggered by remote users over TCP/UDP without authentication (or debug mode)).
FWIW, the attached strace shows the issue; the effects of the call to syslog() that fails start at line 1254.
|