Directory traversal in index.php

Bug #1093967 reported by Amril Jafni Joehari on 2012-12-27
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Fix Released
Alex Harrington
Fix Released
Dan Garner
Fix Released

Bug Description

Hi Xibo Team,

Our pentesters (Detica - BAE Systems) have found a directory traversal vulnerability in Xibo 1.2.2. We have tested on version 1.2.2 and 1.4.1 in our staging environment. The bug exist on "p" parameter in index.php and unauthenticated users can exploit the bug.


Expected output will show the content of /etc/passwd if the server is running Linux.

Please email me for screenshot and details.

information type: Private Security → Public Security
information type: Public Security → Private Security

Thanks for reporting this Amril. We'll confirm and look at releasing a patch shortly.

I've had a bash at confirming and it doesn't seem to work for me. I've tried the string you gave and ammending the number of ../ appropriately but I can't get the contents of /etc/passwd to show.

What it's doing is adding .class.php to the name supplied in the p= query so the target file isn't opened, however you're absolutely correct that this has potential to be exploited to execute code uploaded by a third party to a different folder on the server.

The p= argument needs to be sanitised to remove ../ characters or some similar fix.

I'll mark as confirmed and we'll get a patch out.

Many thanks for your help finding this.

Changed in xibo:
status: New → Confirmed
importance: Undecided → Critical

Kit seems to allow ../ as part of a word validation here:

Then on creation of the PageManager class, that string is used without further validation here:

Thank you for looking into this. I am looking forward for the patch.

Please try the following:
In kit.class.php, please replace line 286 as follows:

$return = (string) preg_replace( '/[^A-Z_-]/i', '', $return );

So the whole section reads:
   case _WORD :
    if ($return == '')
     $return = '';

    $return = (string) preg_replace('/[^A-Z_-]/i', '', $return );

I'm testing this on one of my systems and will look for any unintended side effects

Note the above will prevent the reported exploit, however there should still be code on creating a PageManager class to check for the existence of the loaded class and give a graceful error if it doesn't exist.

I am testing this out in our staging environment. will revert back if there are any issue found.

I've not seen any issue as a result of this change. Amril has it been OK for you?

We have also did the advised changes on our staging env. The vulnerability is no longer exploitable. Currently we are still waiting a response from functional testing. So far all seems OK.

Thanks for the update. Assuming no issue is found, my proposal would be that we quietly merge this in to the next release and produce a 1.2 patch for those needing to continue running 1.2. We can say that it fixes a security issue but be non-specific about what the bug was - we'll just link to this report (which they won't be able to read as it's currently private).

Once that's been released for a month or so, having given people a chance to upgrade or patch their systems, I'll set the visibility of this bug to public and those interested can pick over the notes if they wish.

Does that seem reasonable - Dan?

Also still need to implement validation before we try and load a class with the PageManager - but suggest we only include that in 1.4.2 onwards as it's not important to fixing this issue completely.

Dan Garner (dangarner) wrote :

Yes that works well for me, I will implement your fix and some extra validation on the Page Manger class.

It's really hard to read the diff because it looks like the line indenting was changed so it thinks the entire file is new :(

So as I understand it there's a check if the user is authenticated for that module. If the module doesn't exist in the DB then users that aren't SuperAdmins will fail that check and the code indicated in p= will never be loaded?

If I've understood it correctly then yes that sounds fine.

Dan Garner (dangarner) wrote :

I did rewrite the entire file... it was loading the file requested by "p" before it had validated security. Now it will always either a) validate security in the DB, or b) check that p is in the following array:

private $nonAuthedPages = array('index', 'clock');

mahendra (mahendra-0) wrote :

Hi Xibo Team,

I am Mahendra from BAE Systems Detica which performed pentest for Amril and identified this vulnerability.

May i know when are your team will release the patch to public? We want to release an advisory of this issue on our website.

Thank you.

It will be part of 1.4.2 which will be released soon.

We'd ask you not to release any details of the exploit until 1 month after release to give end users time to upgrade.

We will then make the contents of this bug public so peopld have a full disclosure of the issue.

Do I take it no issues were found in your functional testing with this patch applied?

mahendra (mahendra-0) wrote :

Hi Alex,

No worries, we will follow your procedures for releasing the advisory.

We have not done any tests yet after the patch has been applied by Amril and team, thus i cannot confirm this one for you yet.

How would you like to be credited in the release note? BAE Systems Detica?

Best wishes


mahendra (mahendra-0) wrote :

Hi Alex,

Can you credit it as Mahendra, BAE Systems Detica ?

Thank you

Certainly. Thanks for your help with this.

Marked as public

information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers