FreeRadius is prone to an SQL injection vulnerability. This issue is due to a failure in the application to properly sanitize user-supplied input before using it in an SQL query. Successful exploitation could result in a compromise of the application, disclosure or modification of data, or may permit an attacker to exploit vulnerabilities in the underlying database implementation. http://www.securityfocus.com/bid/13540/info/
Alin, please advise.
*** Bug 91754 has been marked as a duplicate of this bug. ***
Also a buffer overflow vulnerability: http://www.securityfocus.com/bid/13541 No real info on these yet, I'm keeping my eye out with upstream, and maybe a CAN will appear.
I mailed primoz.. waiting for answer good night :-)
Primoz replied! twice: [quote] Hello, please check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307720 Copy paste: In /src/modules/rlm_sql/rlm_sql.c there are few possible problems (IMHO). In sql_escape_func (line 406) there is a loop with special break condition in line 414 ("if (outlen <= 1)"), which is fine unless we have three (3) or less characters available and input character needs escaping (with =XX). In this case this loop causes minor buffer overflow (few characters). As output buffer is huge, this should not be easily exploitable problem. (you should change to outlen <= 3) The other three problems are in lines 520, 1152, 1196 where radius_xlat is called for generation of sql query for execution. It's called without escape function (NULL), which is afterwards replaced with simple copy. As this queries may contain reference to user supplied data (username ...), this may result in SQL injection. This is also hard to exploit as user has to be authenticated already before any of these sql statements can get executed. you should replace NULLs with "sql_escape_func" Regards, Primoz [/quote] [quote] Hello, While you're at work you can check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307796 as well (before Debian converts it to security announcement) Throwing the code out, using the stupid patch provided bellow or using mysql real escape function helps. Primoz [/quote]
Created attachment 58267 [details, diff] xtradius: sql injection in authmysql Proposed stupid-patch for the testing distribution. If there isn't apex in the supplied argumenti it's impossible to modify the SQL query. Bye, Gerardo
Adir, please explain how you proposed patch solve the problem? I am in the process of creating a patch for the problem explained in Debian bug but it will modify only rlm_sql.c
fixed in 1.0.2-r3. if it is serious enough to issue a glsa, it needs to be marked as stable on x86. the current stable version (1.0.1) is vulnerable as well.
x86 please test and mark stable. Alin we mark stable before deciding on GLSA release.
marked x86 by me
Thx Alin, this one is ready for GLSA decision.
I tend to vote YES on this one.
Voting YES.
Pulling in auditors to verify wether the buffer overflow is exploitable.
The bug at line 406 looks like it should be exploitable to me. The user has rough control over what goes on the stack, the limit being the fact they need to find a charater whose mime encoding is what they would like ;) My lack of knowledge of mime encoding prevents me from giving a quick yes/no answer. The correct phrasing for me is probably: "cannot be guaranteed not to be exploitable". The other bugs seem less likely as the author mentions, they have to have already authenticated without causing SQL to barf.
GLSA 200505-13
The patch provided in the Gentoo package 1.0.2-r3 introduces a new bug. http://www.gentoo.org/cgi-bin/viewcvs.cgi/net-dialup/freeradius/files/freeradius-1.0.2-sql-escape.patch?rev=1.1 In sql_set_user the resulting string will be escaped twice (it will make things wrong if there's an escape candidate character in the username). You can find upstream a patch that works: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/src/modules/rlm_sql/rlm_sql.c.diff?r1=1.131.2.1&r2=1.131.2.3 Following is my personal opinion about this matter: - This is very disapointing that no mail was send to the FreeRADIUS developpers <freeradius-devel@lists.freeradius.org> before publishing the GLSA. - The severity should be "low" and not "high". The buffer overflow allows to write two characters beyond the limit: one in [0-9A-F] and a '\0'. It is very hard (if possible at all) to do anything with this.
Nicolas, Sorry about the misunderstanding... We (mistakenly) thought that either the BugTraq poster or the Debian maintainer (from which we got the bug from) had tried contacting you. We'll fix this with your (obviously better) patch and issue an update to our GLSA. We'll confirm with our audit team that the buffer overflow is indeed non-exploitable and fix the severity if needed. You might want to push your patch to Debian too before they release their own Security Advisory too, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307796 for pointers. =================================================== mrness, a revision is in order to include upstream patch.
Nicolas sorry for the misunderstanding, it was not our discovery so we didn't inform you. I've just talked with taviso (one of our auditors) and reports that the two byte overflow is very unlikely to result in code execution.
my apollogies about that. freeradius-1.0.2-r4 commited, using the upstream patch. that should fix this bug, but it is security's bug (not my teritory)
Auditors/Alin does the overflow result in DoS or just the crash of a child?
arrrgh.. that's why I hate upstream patches! Always have RCS shit in them!!! I've fixed the fix by removing RCS garbage from the patch Our init.d script does not use radwatch, it directly starts the radiusd daemon. If we use radwatch, the potential DoS will not be possible. Do you want me to fix that?
Alin, if it's a security improvement and there are no downsides to this please use radwatch. Please confirm that the buffer overflow will be full DoS on our FreeRadius?
done in 1.0.2-r5. now we use radwatch, which make DoS impossible. I don't know if DoS is possible in previous version.
Use CAN-2005-1454 for the overflow. Use CAN-2005-1455 for the SQL injection issues.
Thx Nicolas for bringing this to our attention. GLSA ERRATA sent.
Hmm, but 'man radwatch' says: This script SHOULD NOT BE USED! It's only here for historical purposes, and WILL be deleted in a future version of the the server. Please see 'doc/supervise-radiusd.txt' for info on methods of supervising your radius installation. So perhaps we should look for another solution to prevent DoS?
radwatch is a siple bash script (please loog at bug #93158, especially at comment no 10) if you prefer daemontools and managed to use freeradius with it, I'm open to receive enhancements.
