Created attachment 425 [details] Screens & details of vulns Hello IPFire team, I'm contacting you to report to you several vulnerabilities that are present in the latest IPFire 2.17 i586 Core Update 99 version (and older). IPFire (as IPCop) implements a "referer checking" mecanism in his web administration panel to prevent CSRF attack. But there are several input accross pages not sanitized sufficiently that permit Cross-Site Script (XSS). Through these XSS and attacker can bypass the CSRF protection and execute all CSRF that he wants. To illustrate these XSS (in GET or POST), you can find several screens here : https://www.asafety.fr/data/20160403-IPFire_2.17_RXSS001.png https://www.asafety.fr/data/20160403-IPFire_2.17_RXSS002.png https://www.asafety.fr/data/20160403-IPFire_2.17_RXSS003.png The GET XSS affecting the ipinfo.cgi script (IPCop had the same several month ago but it's fixed now) can be used to load third-party JS script. This third-party script can perform CSRF attack. The proxy.cgi script has another vulnerability more critical. We can execute command on the IPFire server through this page. With specialy crafter POST param targeting the proxy.cgi page, an attacker can obtain a full reverse-shell on the IPFire distro. And attacker can chain these vulnerability to gain a reverse-shell with just one URL sent to an IPFire's admin (phishing / spear-phishing). I've realise a demonstration video (private) of these vulnerabilities. You can see it here : https://www.youtube.com/watch?v=rBd21aXU83E I join a full private advisory with all details of these vulns here : https://www.asafety.fr/data/20160403_-_IPFire_2.17_i586_Core_Update_99_Remote_Command_Execution.txt I post this topic here on the forum because I have never receive activation email from https://bugzilla.ipfire.org/, and you don't provide a specific mail address for security issues. I have found this Bug Bounty topic : http://forum.ipfire.org/viewtopic.php?t=15021 but no contact address. There is an IPFire Bug Bounty? Please feel free to contact me if you need more information, These security issues were originally posted on the ipfire forum (private topic) here : http://forum.ipfire.org/viewtopic.php?f=3&t=16251&p=96611 Some exchange were made between me and MichaelTremer. All details are not publicly available. Advisory, screens and video are just share with you here for security concerns. Yann CAM - Security Consultant @ASafety and IPFire user | yann.cam@asafety.fr..
Created attachment 426 [details] ipinfo.cgi: Remove XSS vulnerability Thanks for submitting this bug report. I am not sure how we can tackle all the issues reported here at once. Some are easier to solve, some are more complicated to solve. For a start I fixed the XSS vulnerability in ipinfo.cgi. Could you please review this and confirm that this patch solves that issue?
(In reply to Yann CAM from comment #0) > All details are not publicly available. Advisory, screens and video are just > share with you here for security concerns. Is there anything else you want to share? You can do so in this ticket.
Comment on attachment 426 [details] ipinfo.cgi: Remove XSS vulnerability I think it's a good fix, but it's generally better to applied sanitization when data are displayed/printed. So in ipinfo.cgi, the "$hostame" var need to be cleared / escaped / encoded before printing here : &Header::openbox('100%', 'left', $addr . ' (' . $hostname . ') : '.$whoisname); It's the same for all POST data re-printed after form submission in mail.cgi (cf previous screen). Or in logs.cgi with the "ip" POST param.
(In reply to Michael Tremer from comment #2) > (In reply to Yann CAM from comment #0) > > All details are not publicly available. Advisory, screens and video are just > > share with you here for security concerns. > > Is there anything else you want to share? You can do so in this ticket. All details are in attachment (advisory txt file).
(In reply to Yann CAM from comment #3) > Comment on attachment 426 [details] > ipinfo.cgi: Remove XSS vulnerability > > I think it's a good fix, but it's generally better to applied sanitization > when data are displayed/printed. > > So in ipinfo.cgi, the "$hostame" var need to be cleared / escaped / encoded > before printing here : > > &Header::openbox('100%', 'left', $addr . ' (' . $hostname . ') : > '.$whoisname); > > It's the same for all POST data re-printed after form submission in mail.cgi > (cf previous screen). > Or in logs.cgi with the "ip" POST param. I agree with that. However it is almost infeasible to do this very quickly. This code is from the 90's where nobody took care of this. (In reply to Yann CAM from comment #4) > (In reply to Michael Tremer from comment #2) > > > > Is there anything else you want to share? You can do so in this ticket. > > All details are in attachment (advisory txt file). Ok. That sounded to me like there were other things.
Created attachment 427 [details] {proxy,chpasswd}.cgi: Fix a remote code execution vulnerability This is a patch to fix the "htpasswd" command execution vulnerability. Again, please review this and send me any feedback. We implemented a CSRF token in the next version of the IPFire Web user interface. However, this is not as easy to do this with the legacy one. We have the referrer check in place where ever we can. However, there are still plenty of input validation issues in the web user interface that I cannot fix just today. I would also like to rank them second to the command injection vulnerabilities. Do you have any more of these that require an immediate fix? Should we make this bug report public again since for the two biggest issues that you reported are fixes available?
(In reply to Michael Tremer from comment #6) > Created attachment 427 [details] > {proxy,chpasswd}.cgi: Fix a remote code execution vulnerability > > This is a patch to fix the "htpasswd" command execution vulnerability. > > Again, please review this and send me any feedback. Using the Apache::Htpasswd module is the best way to secure the change password mecanism rather than system("/usr/sbin/htpasswd [...]") with unsanitized $variables. > > We implemented a CSRF token in the next version of the IPFire Web user > interface. However, this is not as easy to do this with the legacy one. We > have the referrer check in place where ever we can. Good to ear ! And I understand well that it's a big work to implment CSRF token... As said in the forum topic : There are 3 main mecanisms to protect again CSRF attack : - Referer checking (good but insufficient if an XSS is discovered) - CSRF token (best method, but insufficient if an XSS is discovered too) - "document.opener" analyzer on client-side with JavaScript (undocumented method, insufficient because controls are done client-side). So with the actual referer checking, IPFire prevents CSRF attack, while there is no XSS found. There are very few GET params in IPFire web admin console. Most of forms submits data through POST, so referer is checked. > > However, there are still plenty of input validation issues in the web user > interface that I cannot fix just today. I would also like to rank them > second to the command injection vulnerabilities. I agree : fix the XSS in ipinfo.cgi and the Command Exec vuln are prioritary. > > Do you have any more of these that require an immediate fix? Not for the moment (I haven't spent more time to check IPFire source code). But to be sure, it's possible du grep dangerous functions calls in all *.cgi file, like "system(" for exemple, and check the sanitization of $variables passed to these calls. > > Should we make this bug report public again since for the two biggest issues > that you reported are fixes available? Yes, I think it's a good plan to make this bug report public once the GET XSS (in ipinfo.cgi) and the RCE are fixed. Others POST-XSS are quite unusable for an attacker while the referer checking is in place, and no more RCE are discovered.
Okay, this sounds good. We will release Core Update 100 hopefully be the end of this week. It is already uploaded to the mirror servers so I cannot ship the fixes with this one. As soon as it is release, we will prepare for Core Update 101 and then make this report public. At a first glance I did not find any more RCEs. Did you request a CVE number already or should I do this?
Ok, perfect, good job ! :) Just for information, I've received just now my first email from BugZilla. Email body is blank, sender address is "bugzilla@ipfire.org"@web02.ipfire.org, reveiver address is "yann.cam@gmail.com"@web02.ipfire.org and email is dated from 01/01/1970 01:00 (timestamp 0?) I really think that the SMTP server of IPFire BugZilla is in trouble... Email from the IPFire forum work like a charm by the way. (In reply to Michael Tremer from comment #8) > Okay, this sounds good. We will release Core Update 100 hopefully be the end > of this week. It is already uploaded to the mirror servers so I cannot ship > the fixes with this one. As soon as it is release, we will prepare for Core > Update 101 and then make this report public. Ok, noted in my side, I'll wait the new core update. > > At a first glance I did not find any more RCEs. I'll check more deeper when I can. > > Did you request a CVE number already or should I do this? I think you should do, with details, fix, PoC, screens and credits. It's better when the "editor" or official developer of a product / project requests a CVE by himself. Sincerely,
(In reply to Yann CAM from comment #9) > Ok, perfect, good job ! :) > > Just for information, I've received just now my first email from BugZilla. > Email body is blank, sender address is > "bugzilla@ipfire.org"@web02.ipfire.org, reveiver address is > "yann.cam@gmail.com"@web02.ipfire.org and email is dated from 01/01/1970 > 01:00 (timestamp 0?) > > I really think that the SMTP server of IPFire BugZilla is in trouble... This is a bug in Bugzilla. Unfortunately I do not have any time to look into this. > Email from the IPFire forum work like a charm by the way. The mail system is fine. > (In reply to Michael Tremer from comment #8) > > Okay, this sounds good. We will release Core Update 100 hopefully be the end > > of this week. It is already uploaded to the mirror servers so I cannot ship > > the fixes with this one. As soon as it is release, we will prepare for Core > > Update 101 and then make this report public. > > Ok, noted in my side, I'll wait the new core update. > > > > > At a first glance I did not find any more RCEs. > > I'll check more deeper when I can. > > > > > Did you request a CVE number already or should I do this? > > I think you should do, with details, fix, PoC, screens and credits. > It's better when the "editor" or official developer of a product / project > requests a CVE by himself. Okay, will do this. Thank you very much for reporting this issue and helping our project to become better software :)
CVE assignment request is sent.
(In reply to Michael Tremer from comment #10) > > Thank you very much for reporting this issue and helping our project to > become better software :) Your're welcome, it is with pleasure if I can help improve IPFire. (In reply to Michael Tremer from comment #11) > CVE assignment request is sent. Ok, perfect, I've seen : - http://www.openwall.com/lists/oss-security/2016/04/05/5 - http://seclists.org/oss-sec/2016/q2/15 Thank you for your interest and congratulations for your correction reactivity (it's far from being the same for many solutions). Sincerely,
(In reply to Yann CAM from comment #12) > (In reply to Michael Tremer from comment #10) > > > > Thank you very much for reporting this issue and helping our project to > > become better software :) > > Your're welcome, it is with pleasure if I can help improve IPFire. > > (In reply to Michael Tremer from comment #11) > > CVE assignment request is sent. > > Ok, perfect, I've seen : > - http://www.openwall.com/lists/oss-security/2016/04/05/5 > - http://seclists.org/oss-sec/2016/q2/15 > > Thank you for your interest and congratulations for your correction > reactivity (it's far from being the same for many solutions). We are trying our best here :) Unfortunately a CVE ID has been denied. No reason was given so I emailed back. This is not really necessary for me, but I thought it might make it easier to track this issue.
CVE request has been denied again. They apparently only give out IDs to projects on their list which is all Adobe and Cisco so on - and projects on an unwritten list that is not public. What ever this is, we don't need it any ways. So I do not see any more reason to keep this private.
(In reply to Michael Tremer from comment #14) > CVE request has been denied again. They apparently only give out IDs to > projects on their list which is all Adobe and Cisco so on - and projects on > an unwritten list that is not public. What ever this is, we don't need it > any ways. > > So I do not see any more reason to keep this private. Sorry for my late answer ; yes, I agree, there is no more reason to keep this private if a fix and a new Core Update (100) is released. Sincerely,
Hello, just saw that there is a Metasploit exploit available for this: https://www.rapid7.com/db/modules/exploit/linux/http/ipfire_proxy_exec Old systems owners should better update now... ;-) Best regards, Timmothy Wilson
Luckily you need to have login data first :) Must have forgotten to close this...