Date: Thu, 2 Sep 1999 10:36:49 +0200 (MET DST) From: Mohacsi Janos <mohacsi@ik.bme.hu> To: freebsd-security@freebsd.org Subject: amd buffer overflow some Linuxes, in FreeBSD too? Message-ID: <Pine.OSF.4.10.9909021016460.12830-100000@hera.ik.bme.hu>
next in thread | raw e-mail | index | archive | help
Hi, There are some reports that amd is vulnerable to stack overflow remote root exploit attack in some Linux distribution. http://linuxtoday.com/stories/9440.html Can somebody check whether the FreeBSD version also vulnerable? As I see on the amd-dev list the amq -M code is the origin of the remote root exploit. snip from amd-dev list archive: --------------------------------------------------------------------------- From: Erez Zadok <ezk@shekel.mcl.cs.columbia.edu> To: Douglas Alan <nessus@mit.edu> Cc: ezk@shekel.mcl.cs.columbia.edu, amd-dev@cs.columbia.edu Subject: Re: am-utils security hole? Sender: amd-dev-owner@cs.columbia.edu Precedence: bulk X-majordomo-list: amd-dev from majordomo.cs.columbia.edu In message <199908241739.NAA21639@space.mit.edu>, Douglas Alan writes: > Hi. Have you heard anything about an am-utils buffer overrun security > hole? Our RedHat 6.0 computers have all been broken into, apparently > using a bug in amq. Here is the suspicious log entry from > /var/log/messages: > > Aug 21 20:49:51 lagavulin 27>Aug 21 20:49:51 amd[3531]: amq requested > mount of > <90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90> [...] > <FF><BF><D2><F2><FF><BF>^C > > |>oug I verified that the amd distributed with redhat 6.0 is indeed compiled without ENABLE_AMQ_MOUNT. This is the routine that logged the message you reported: #ifdef ENABLE_AMQ_MOUNT <evil code> #else /* not ENABLE_AMQ_MOUNT */ int * amqproc_mount_1_svc(voidp argp, struct svc_req *rqstp) { static int rc; char *s = *(amq_string *) argp; plog(XLOG_ERROR, "amq requested mount of %s, but code is disabled", s); rc = EINVAL; return &rc; } #endif /* not ENABLE_AMQ_MOUNT */ What I find strange is that your logs don't show the "but code is disabled" part. This is probably b/c the string 's' overran the plog (vsprintf) buffer. Another strange thing I found was that as far as I can tell, the amq -M rpc message uses xdr_amq_string exclusively. This xdr routine uses xdr_string(..., AMQ_STRLEN), and AMQ_STRLEN is 1024. That is, I limit the maximum size of an amq rpc message that can be passed to amd. What I'm not sure, however, is if xdr_string will handle a string passed to it that is _exactly_ 1024 bytes long, leaving no space for a terminating null. Anyway, I believe that this buffer overrun was triggered in real_plog(), while logging the message, not in the xdr/rpc code. real_plog() uses temp buffers of a fixed maximum size (1024 bytes), and calls vsprintf(ptr, efmt, vargs); it is this 'ptr' that has a maximum length. But efmt+vargs can be exploited to expand into a string that's longer than 1024 bytes, thus overrunning 'ptr'. I cannot think of a clean way to make sure vsprintf expands a string up to a given length. Anyone? Nevertheless, the safest thing IMHO is to simply avoid including any amq -M code unless the ENABLE_AMQ_MOUNT option is turned on (via configure --enable-amq-mount). So this is what I did: (1) amq/amq.c: while the usage() string hides the -M option if ENABLE_AMQ_MOUNT is off, getopt() was still processing -M. Duh. (2) amd/amq_svc.c (amq_program_1): the RPC dispatch routine still processed amq -M requests, but then called a version of amqproc_mount_1_svc that simply printed "... but code is disabled." I conditionalized the dispatching into amqproc_mount_1_svc on #ifdef ENABLE_AMQ_MOUNT. (3) amd/amq_subr.c: completely removed the amqproc_mount_1_svc() routine that's called when ENABLE_AMQ_MOUNT is not on. The above fixes are now in 6.0.1s11. While they were not throughly tested, I think they are much safer than anything prior to s11, and certainly prior to s10. There may be other possible exploits in the amq/amd RPC interface. I don't have the time now to inspect and analyze them all, but if anyone finds something bad, please send patches. Also, if more security fixes will come up in the next few days, I'll probably have to cut more 6.0.1 snapshots. ------------------------------------------------------------------------ Thanks, Janos Mohacsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.10.9909021016460.12830-100000>