Ubuntu has issued an advisory on May 17: http://www.ubuntu.com/usn/usn-1444-1/ Cauldron/Mageia 2 are also affected.
CC: (none) => juergen.harms
Thank you for picking up this problem. Cauldron currently is un-patched 3.2.1 and is certainly concerned. I understand the problem but need to dig into the update proposed by Ubuntu - see whether it is better to copy the Ubuntu patch or wait for a corresponding patch from upstream (my preferred solution) - and also verify whether.2.0 (Mageia 1) is also concerned. Given the nature of the problem, I dont think that urgent action is necessary before the release of Mageia 2 official
Yes, this isn't urgent. In fact, RedHat has been sitting on it for 3 months without fixing it: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-5081 Some of the references have a proof of concept for the bug, so it shouldn't be too hard to verify if Mageia 1 is affected. Ubuntu did submit their patch upstream, according to: http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-5081.html
Running into a timeout with my question to the backuppc user ML, I realise that a comment I made got lost - probably I did not submit it correctly. Resuming: Applying the PoCs to backuppc (Mageia 1, Mageia 2, cauldron): ------------------------------------------------------------ Both requests to the server proposed in the PoC result in Error: Only privileged users can browse backup files for host localhost (resp. "restore" instead of "browse" for the second request. It looks as if the problem has been fixed in the 2 upstream versions used in Mageia Source code in backuppc 3.2.1 and 3.2.0 --------------------------------------- The patch proposed by Ubuntu (resp. Debian) is not contained in the source contained in the 2 versions of upstream backuppc code - which does not preclude that upstream has resolved the problem in a different way) History ------- The CVE notice dates from late april 2011 - prior to the publishing of upstream backuppc 3.2.0 and 3.2.1. Backuppc does not have a publicly accessible bug tracking system or software repository - it is not possible to assess whether the bug has effectively been cleared. However, according to the references quoted for CVE-2011-5081, the bug is "fixed by vendor". I have sent an email (may 28) to the backuppc user ML asking for confirmation when and where the bug had been fixed - no reply so far, and I am reluctant to sign up the backuppc dev ML. Next actions ------------ I would like somebody else to repeat the PoC scripts on the backuppc server of their installation in order to make sure that my test are conclusive and correct. Following this, I suggest the bug to be closed without further action
So, if you have JavaScript enabled in your browser, this one doesn't give you an alert pop-up? http://host/index.cgi?action=RestoreFile&host=localhost&num=1&share=%3Csc ript%3Ealert%28234%29%3C/script%3E&dir= I guess this is the patch: --- backuppc-3.2.1.orig/lib/BackupPC/CGI/RestoreFile.pm +++ backuppc-3.2.1/lib/BackupPC/CGI/RestoreFile.pm @@ -154,12 +154,12 @@ my $a = $view->fileAttrib($num, $share, $dir); if ( $dir =~ m{(^|/)\.\.(/|$)} || !defined($a) ) { $dir = decode_utf8($dir); - ErrorExit("Can't restore bad file ${EscHTML($dir)} ($num, $share)"); + ErrorExit("Can't restore bad file ${EscHTML($dir)} (${EscHTML($num)}, ${EscHTML($share)})"); } my $f = BackupPC::FileZIO->open($a->{fullPath}, 0, $a->{compress}); if ( !defined($f) ) { my $fullPath = decode_utf8($a->{fullPath}); - ErrorExit("Unable to open file ${EscHTML($fullPath)} ($num, $share)"); + ErrorExit("Unable to open file ${EscHTML($fullPath)} (${EscHTML($num)}, ${EscHTML($share)})"); } my $data; if ( !$skipHardLink && $a->{type} == BPC_FTYPE_HARDLINK ) { It looks like a pretty simple issue of not escaping/sanitizing a couple of variables that can be controlled by user input and used to inject code. I also see another CVE in their ChangeLog that were supposedly fixed by Debian/Ubuntu post-3.2.1; CVE-2011-4923 , with this patch: --- backuppc-3.2.1.orig/lib/BackupPC/CGI/View.pm +++ backuppc-3.2.1/lib/BackupPC/CGI/View.pm @@ -46,7 +46,7 @@ my $compress = 0; my $fh; my $host = $In{host}; - my $num = $In{num}; + my $num = ${EscHTML($In{num})}; my $type = $In{type}; my $linkHosts = 0; my($file, $comment); And it looks like RedHat and Fedora issued advisories for that one too according to this: https://bugzilla.redhat.com/show_bug.cgi?id=749845
Sorry, my reconstruction of the lost comment missed out on an important item: I initially did a local build of backuppc (3.2.1) that applies the patch suggested by Ubuntu (using the patch proposed by Jamie Strandboge). Installing this as my server does not change anything as compared to the un-patched backuppc - sending http://pcjuergen.unige.ch/backuppc/?action=RestoreFile&host=localhost&num=1&share=%3Csc to my server makes backuppc (patched and unpatched) respond with an error page : Error: Only privileged users can restore backup files for host localhost. I am using firefox with javascript enabled - no alert popup. My problem is (and that is why I tried to get feedback from upstream backuppc): according to the CVE notice, the problem has been "fixed upstream". The notice dates from april 2011. Does the ubuntu patch that has been announced many months later fix a problem that has in the meantime been fixed upstream? or is the patch still needed? I have seen the Fedora and RedHat notices - same question. And evidently, not being an educated developper, is my conclusion correct? One solution would be to simply create an update with the patch applied and forget the reasoning - not quite my style. What is Mageia policy?
(In reply to comment #5) > I initially did a local build of backuppc (3.2.1) that applies the patch > suggested by Ubuntu (using the patch proposed by Jamie Strandboge). Installing > this as my server does not change anything as compared to the un-patched > backuppc - sending > > http://pcjuergen.unige.ch/backuppc/?action=RestoreFile&host=localhost&num=1&share=%3Csc Just want to be sure here, since that's not the whole URL (word wrap in Bugzilla cut it off). Did you use the actual whole URL for that PoC? (In reply to comment #5) > My problem is (and that is why I tried to get feedback from upstream backuppc): > according to the CVE notice, the problem has been "fixed upstream". The notice > dates from april 2011. Does the ubuntu patch that has been announced many > months later fix a problem that has in the meantime been fixed upstream? or is > the patch still needed? I have seen the Fedora and RedHat notices - same > question. And evidently, not being an educated developper, is my conclusion > correct? There seems to be a lot of conflicting information out there about this one, some say it's fixed in 3.2.1, some say 3.2.1 is still vulnerable, and some say they aren't sure if 3.2.0 is vulnerable or if only 3.1.0 is. Judging by the code, it looks like it was not fixed in 3.2.1 and the patches are needed. One of the older CVEs was in fact fixed in 3.2.1 (and was patched in our package when it was only 3.2.0), but the two newer ones have come out post-3.2.1. (In reply to comment #5) > One solution would be to simply create an update with the patch applied and > forget the reasoning - not quite my style. What is Mageia policy? We're not always able to reproduce a security problem, even with PoCs (you never know how reliable they are), but that doesn't stop us from issuing an update. Best bet would be to issue the update so long as it doesn't cause any regressions. I guess the philosophy would be if we're going to possibly be wrong one way or the other, let's err on the side of caution. I would suggest building an update with the two patches in Comment 4, and if you don't see any regressions yourself, push it to QA.
Thank you for your detailed reply, and yes, that makes sense. The CVE notes are a mess and in countradiction, for instance - http://secunia.com/advisories/44385 says "Solution Status Unpatched" - https://www.htbridge.com/advisory/HTB22965 says "Fixed in new release 3.2.1 on SourceForge.net" The intransparency in backkupc software management is not very helpful either. > Just want to be sure here, since that's not the whole URL (word wrap in > Bugzilla cut it off). Did you use the actual whole URL for that PoC? Ooops, I did not see this when writing my comment. But yes, the URL I submitted was the complete url - the request was correctly recognized by the server, handed over to and, according to evidence, correctly processed by backuppc. > I would suggest building an update with the two patches in Comment 4, and if > you don't see any regressions yourself, push it to QA. I will do that and, as you suggest also include the patch for CVE-2011-4923 Seeing the ongoing discussion on bugs that need to be fixed in more than one branch (cauldron, 1, 2 in this case), I suggest to stay on the safe side and open additional bugs for Mageia 2 and cauldron (just with a reference to bugzilla 6005 - up to the bug-sqad to decide which depends on and which and which blocks which). I intend to create an update for cauldron first - I just started acting as maintainer and am still a packaging apprentice, that is the most sure approach for me.
After some more searching and looking at source code (the upstream CVS repository is at http://backuppc.cvs.sourceforge.net) - the reasoning is now clear: Patches required ---------------- CVE-2011-4923 ... nothing done upstream so far: this patch must be applied to Mageia 1, 2 and cauldron. CVE-2011-5081 ... in fact, has not been fixed upstream: the patch from Ubuntu therefore must be installed on all 3 branches(the upstream fix - see details below - corrects something else, is complementary to the Ubuntu patch). CVE-2011-170886 ... had already been added to the Mageia versions that use 3.2.1 during Mageia 2 pre-release: needs to be added to 3.1.0 (Mageia 1), it is required to avoid perl warnings due to obsolete syntax. I still do not understand the PoCs suggested: the CVE-2011-5081 patch only concerns the detection of non-numerical values specified in requests, but the suggested PoC tests something else. Details on the fix in the upstream CVS -------------------------------------- Introduced in response to CVE-2011-5081: http://backuppc.cvs.sourceforge.net/viewvc/backuppc/BackupPC/lib/BackupPC/CGI/Browse.pm?r1=1.23&r2=1.24 This fix dates from 25 april 2011 (one day after the release date of backuppc-3.2.1), but has been backported to the SourceForge repositories for 3.2.1 and 3.2.0: therefore backuppc in Mageia 1, 2 and cauldron already contain this fix. The fix is different from the patch proposed by Ubuntu: the fix and the Ubuntu patch both detect non-numerical values in requests - but the upstream fix only corrects the "browse" function, the Ubuntu patch only the "restore" function (and CVE-2011-4923 applies a similar correction yet in another module). I have now pushed an update to cauldron (backuppc-3.2.1-6), will push the updates for Mageia 1 and 2 shortly
I did a typo: please read (comment 8, Details paragraph) : ... has been backported to the SourceForge repositories for 3.2.1 and 3.1.0
Sorry for the confusion between backuppc versions - the upstream fix has been backported to 3.2.0 and 3.1.0 - Mageia 1 uses 3.2.0. The patched versions have been pushed to updates_testing on Mageia 1 and 2, there is now in core/updates_testing to validate backuppc-3.2.0-5.mga1 and backuppc-3.2.1-6.mga2 Suggested advisory: (drop CVE-2011-170886 in the Mageia 2 advisory) ------------------- This update adds patches against the following CVEs: - CVE-2011-5081 - CVE-2011-4923 - CVE-2011-170886 Steps to reproduce/put in evidence: ----------------------------------- This is the first time I push an update like this - I hope this is not too long - install or update backuppc - in your browser, request the following URLs, replacing the lead part by the address of your backuppc server (for me this is: pcjuergen.unige.ch/backuppc/ ) CVE-2011-5081 http://seclists.org/bugtraq/2011/Apr/266 CVE-2011-4923 PoCs suggested in this notice better: <host>/BackupPC_Admin?action=browse&host=<client>&num=<value> <client> ... the address of the client to browse/restore <value> ... the numeric value of the backup number using some string containing non-digits, or a digit string that refer to a non-existing backup number should create a backuppc error screen or <host>/BackupPC_Admin?action=RestoreFile&host=<client>&num=<value>&share=<share>&dir=/<directory> <client> and <value> ... as above, <share> ... a backuppc target share as defined in /etc/backuppc/<targethost>.pl <directory> ... the directory to restore an incorrect string for <value> or references to a non-existing <share> or <directory> should create a backuppc error screen CVE-2011-4932 http://www.openwall.com/lists/oss-security/2011/10/27/8 Urls given in the 5th line of the short letter to Craig CVE-2011-170886 No test at install or use time - the patch should avoid warnings on obsolete perl syntax during package build
Assignee: bugsquad => qa-bugs
Thanks Juergen. CVE-2011-170886 isn't a valid CVE number and it doesn't look like a security fix. Maybe 170886 corresponds to a (perhaps upstream) bug number. Also, information about that fix doesn't look relevant to users. In the advisories we usually give a short description of the CVE (from the CVE URL if it's not reserved) and references, including the CVE URLs and other sources of information we used for the advisory or fix. Finally, we also list at least the list of source RPMs uploaded so that QA knows exactly what they're supposed to be testing (and also to make sure that someone hasn't replaced it with a newer version without updating the advisory) and also so that the sysadmins know what to push. Suggested Advisory: ======================== Updated backuppc packages fix security vulnerabilities: Cross-site scripting (XSS) vulnerability in RestoreFile.pm in BackupPC 3.1.0, 3.2.1, and possibly other earlier versions allows remote attackers to inject arbitrary web script or HTML via the share parameter in a RestoreFile action to index.cgi (CVE-2011-5081). Cross-site scripting (XSS) vulnerability in View.pm in BackupPC 3.0.0, 3.1.0, 3.2.0, 3.2.1, and possibly earlier allows remote attackers to inject arbitrary web script or HTML via the num parameter in a view action to index.cgi, related to the log file viewer (CVE-2011-4923). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4923 http://www.ubuntu.com/usn/usn-1444-1/ ======================== Updated packages in core/updates_testing: ======================== backuppc-3.2.0-5.mga1 backuppc-3.2.1-6.mga2 from SRPMS: backuppc-3.2.0-5.mga1.src.rpm backuppc-3.2.1-6.mga2.src.rpm
Thank you, this is constructive and helps me for next time. OT with respect to this bug: - https://wiki.mageia.org/en/Example_update_advisory_announcement might do with some substantial improvements.
Verified XSS attach with URL http://<my_server>/BackupPC_Admin?action=view&type=XferLOG&num=<script>alert(123)</script>&host=<my_host> This causes a box to appear in the centre of the screen containing the text 123. Upgraded to backuppc-3.2.1-6.mga2.src.rpm verified XSS attack no longer succeeds verified continued normal operation of backuppc update verified for x86_64
CC: (none) => derekjenn
Whiteboard: (none) => mga2-64-OK
Testing x86_64 Mga1 Installed, configured /etc/backuppc/config.pl and started the backuppc service. Browsing to: http://<server ip>/backuppc/BackupPC_Admin?action=view&type=XferLOG&<script>alert(123)</script>&host=<my ip> (CVE-2011-5081) or http://<server ip>/backuppc/BackupPC_Admin?action=view&type=XferErr&num=<script>alert(123)</script>&host=<my ip> (CVE-2011-4932) Causes the alert. after update it shows an error page. I don't understand how to configure this to make an actual backup but the service starts and the web interface connects to it and the various data pages display ok. Ideally I'd like to test a backup if you can supply a sample config but this shows the service is starting and appears to be working and the CVE's are fixed.
Version: 1 => 2Whiteboard: mga2-64-OK => MGA1TOO mga2-64-OK
Hardware: i586 => All
Actually both of the above url's relate to CVE-2011-4932
Created attachment 2456 [details] My standard backuppc configuration
Created attachment 2457 [details] My memo for configuring backuppc
Thanks Juergen :)
Is there an separate rpm package for clients?
CC: (none) => davidwhodgins
Ignore comment 19. After more reading of http://backuppc.sourceforge.net/faq/BackupPC.html#requirements I now understand that backuppc can initiate an ssh connection to the client and then start rsync on the client.
Sending my config.pl was a good idea (all my changes are marked with, helps to find where you have to put your site specific info). My directory setup (described in the memo) makes things too complicated - I mount /server on a separate disk (have all configuration data there to be autonomous in case of a crash: You better keep the host information locally in the /etc/backuppc directory, the backup data directories /var/lib/backuppc/ -as foreseen in the package. For your tests, use the server machine also as a backuppc client (described by an entry in /etc/backuppc/pc/...). You can than manually trigger a save on this client, and do restores. The backuppc package already defines the apache server for backuppc. What I do not remember is how you define passwords for apache - there exists a utility - or, just modify the backuppc server definition in apache and suppress authentification. One more attachment: the client description for my client that sits on the server machine
Created attachment 2462 [details] backuppc client definition example
Update verified for Mageia 2 i586
Whiteboard: MGA1TOO mga2-64-OK => MGA1TOO mga2-64-OK mga2-32-OK
There is now also https://bugs.mageia.org/show_bug.cgi?id=6530 you might consider postponing the remainder of QA until this new bug is fixed too - given the nature of the bugs that should be justified Juergen
New packages have been uploaded by Juergen to address the issues in Bug 6530: backuppc-3.2.0-6.mga1 backuppc-3.2.1-7.mga2 Juergen, could you provide a blurb to be added to the advisory explaining what users/admins need to know about the latest changes? Thanks.
Blocks: (none) => 6530
Was being done, had a collision between comment 25 and my comment in Bug 6530
Sorry, thanks Juergen. Using this bug for the Mageia 2 update and Bug 6530 for the Mageia 1 update as stated in https://bugs.mageia.org/show_bug.cgi?id=6530#c8
Summary: backuppc new security issue CVE-2011-5081 => backuppc new security issue CVE-2011-5081 and CVE-2011-4923 [mga2]Whiteboard: MGA1TOO mga2-64-OK mga2-32-OK => mga2-64-OK mga2-32-OK
Advisory: ======================== Updated backuppc packages fix security vulnerabilities: Cross-site scripting (XSS) vulnerability in RestoreFile.pm in BackupPC 3.1.0, 3.2.1, and possibly other earlier versions allows remote attackers to inject arbitrary web script or HTML via the share parameter in a RestoreFile action to index.cgi (CVE-2011-5081). Cross-site scripting (XSS) vulnerability in View.pm in BackupPC 3.0.0, 3.1.0, 3.2.0, 3.2.1, and possibly earlier allows remote attackers to inject arbitrary web script or HTML via the num parameter in a view action to index.cgi, related to the log file viewer (CVE-2011-4923). Also, This update package corrects/improves the definition of variables in config.pl, the configuration file of backuppc: the variables SshPath, SmbClientPath, NmbLookupPath, TarClientPath, TopDir. As a result, backuppc should now run with the default values installed by the Mageia package, modifications of config.pl should only be required for defining site-specific settings. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4923 http://www.ubuntu.com/usn/usn-1444-1/ ======================== Updated packages in core/updates_testing: ======================== backuppc-3.2.1-7.mga2 from backuppc-3.2.1-7.mga2.src.rpm
removing whiteboard entries since there's now a new update to test
CC: (none) => stormiWhiteboard: mga2-64-OK mga2-32-OK => (none)
validated x86_64 Confirmed that programme paths were corrected in configure.pl and that XSS vulnerabilities were gone.
Whiteboard: (none) => MGA2-64-OK
validated i586 Could someone from sysadmin please push backuppc-3.2.1-7.mga2.src.rpm from core/updates/testing to core/updates Advisory: ======================== Updated backuppc packages fix security vulnerabilities: Cross-site scripting (XSS) vulnerability in RestoreFile.pm in BackupPC 3.1.0, 3.2.1, and possibly other earlier versions allows remote attackers to inject arbitrary web script or HTML via the share parameter in a RestoreFile action to index.cgi (CVE-2011-5081). Cross-site scripting (XSS) vulnerability in View.pm in BackupPC 3.0.0, 3.1.0, 3.2.0, 3.2.1, and possibly earlier allows remote attackers to inject arbitrary web script or HTML via the num parameter in a view action to index.cgi, related to the log file viewer (CVE-2011-4923). Also, This update package corrects/improves the definition of variables in config.pl, the configuration file of backuppc: the variables SshPath, SmbClientPath, NmbLookupPath, TarClientPath, TopDir. As a result, backuppc should now run with the default values installed by the Mageia package, modifications of config.pl should only be required for defining site-specific settings. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5081 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4923 http://www.ubuntu.com/usn/usn-1444-1/
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: MGA2-64-OK => MGA2-64-OK MGA2-32-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0139
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED