CRITICAL: REMOTE ROOT exploit for trixbox in the wild
Submitted by voxter on Tue, 07/15/2008 - 7:26pm.
Hello community..
I logged in to my trixbox today, only to discover that it had been remotely exploited. How could this be, I wondered? With my history of forensic analysis of common exploits and DDoS activity, I got to work. My machine was infact connected to an IRC server at irc.flashchat.net with a random nickname.
I started digging a little deeper, and found a file in /tmp called ".k" which contained the perl script necessary to connect to the IRC server. You might want to check your boxes for this file as well, to see if your machine has been compromised.
Oh yeah, and I tracked down how it was exploited, too! :)
There is a vulnerability in /user/index.php by exploiting the code which selects the language you wish to be displayed. This is present in all versions of TrixBox, up to and including 2.6.1.
After digging some more, I found that someone else discovered this exploit just a few days ago and has already contacted fonality about it. I performed a yum update and upgrade, but I am still vulnerable. This exploit not only allows for remote execution of commands as the asterisk user (which httpd runs as, how silly) but since the asterisk user is permitted to execute commands as root via sudo by default (uhh.. guys? hello?) you are able to obtain a remote ROOT shell in about 5 seconds.
Here is an example of me rooting a brand new trixbox server:
# perl tblocalfile.pl my.poor.trixbox.server.com
Choose:
1> Remote Root/Asterisk shell
2> Read a file from the remote server
: 1
Which uid would you like for your shell ? (uid=root will be OK on most recent trixbox versions only): [root|asterisk] root
Press enter to continue...
bash: no job control in this shell
bash-3.1# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
bash-3.1#
Dear Fonality: These exploits are real and they are in the wild. Its been at LEAST a week since you have been notified of this problem, and there's still no patch available. This is more than a "possible threat" - Ive talked to two other people besides myself today who have been hit by a worm looking for this hole.
Dear Trixbox CE users: I would suggest updating every hour if need be so you can get the patch as soon as Fonality decides to release it
Credits:
Jean-Michel BESNARD of LEXSI Audit.
I am not going to defend
Tue, 07/15/2008 - 7:51pm
I am not going to defend Fonality however I am going to decry lousy system administration.
No matter what the source of any software, even internal we assume it is insecure.
Why would I allow my users access to the PBX web screen, on the same network? Why would you place the machine on the Internet?
An access list (where ever you would like to run it) to only allow admins to access administrative services.
An example is SNMP, why would you allow any host in the network read or read/write access?
If you did not like the sudo'ers privs then why did you not change them? What is your business process for introducing a server into the production environment?
You can't trust any software commercial or open source, period.
I don't blame others for the consequences of my actions.
Scott
--
Scott
aka "Skyking"
Quote:
How about doing one
Tue, 07/15/2008 - 8:06pm
Quote:
How about doing one better and providing a workaround until the exploit is patched?
Move index.php out of the web directory so that it's not accessible. You will lose access to the trixbox web stuff, but who cares?
Also, as Scott said, put your trixbox in a DMZ, or at the very least do not expose servers to the Internet unnecessarily. In a small office with no computer savvy users this would probably not be an issue as long as it's not accessible from the Internet (that is not to say that it's OK to take no other security precautions.)
Thanks for the heads up voxter.
To SkyKingOH, mjoyner, my
Tue, 07/15/2008 - 8:32pm
To SkyKingOH, mjoyner, my apologies for not suggesting workarounds.
Like KodaK suggested, I would also suggest not putting your servers on the public internet. Or firewalling tcp port 80 from only trusted sources (or all ports for that matter) or, yes, moving /var/www/html/user/index.php to /var/www/html/user/index.php.old or something, for the time being.
To do this, as root at a command prompt simply run:
mv /var/www/html/user/index.php /var/www/html/user/index.php.old
From there you can still access your configuration gui at http://your.ip.or.hostname/maint/
I took a bit of an assumption that not everyone would be affected by this. Clearly there are people here who administer systems better than others, but there are a good handful of people (see #trixbox, #asterisk on freenode) that have come into this as total beginners and have no idea what they're doing.
It's unfortunate, but its true. I just wanted to warn people that it was a big problem, and more importantly, expose it so that hopefully Fonality will rush a fix out for this!
Voxter
Quote:
i have 5060 forwarded
Tue, 07/15/2008 - 9:20pm
Quote:
i have 5060 forwarded and 50001 forwarded both udp
And I got a bit angry and took an attitude in my post, I apologize. Thanks for the follow up post.
Rather than look to publishers to secure their products I try to preach best practices that are universal. They don't cost anything to implement and are universal from the smallest home office to the largest enterprise. Once these habits become practices problems disappear. I beat my head against the wall when I talk about VLAN's and other simple to implement practices. How can one argue against using the capabilities of the equipment they have?
Besides, there are so many more things to beat Fonality up about. I am far more concerned with the integrity of the repository and the lack of execution on the 'patch plus' strategy.
Heck, nslookup is missing from the latest build and that was pointed out far more than 5 days ago. I try and pick my battles.
Scott
--
Scott
aka "Skyking"
ANYONE (this means you) who
Tue, 07/15/2008 - 9:23pm
ANYONE (this means you) who puts there system on the internet (YOU) is an IDIOT!
In fact the remote index.php exploit was posted 4 + days ago so if you didnt fix it and your exposed your bad....
My guess is this is just another troll trying to stir crap up.
if you have the ability to do a "Forensic Analysis" you would be smart enough to fix it or not expose your self in the first place so back to that
Your an idiot who wants to sound smart
your a troll who is stirring stuff up
hmmmm maybe both
ADDman,
I'm not looking to
Tue, 07/15/2008 - 9:47pm
ADDman,
I'm not looking to sound smart, and im not concerned about the machine that got infected. In my case, this is not a box I care about, and I put it on the public internet on its own network on purpose. I'm glad it got infected like it did, because this allowed me to see what was going on and let everyone else know.
The point was not that I intended to fix it immediately, the point was simply to let other people know what was vulnerable, and thats what I did.
If you want to call me a troll for stirring stuff up, be my guest. But I can guarantee you this: There ARE people who put machines on the public internet because they infact do not know any better. Those people deserve to know what to expect. And Fonality is responsible for releasing a patch that does not require the user to know how to 'patch' their system by some manual means. It should have been available as a security fix (and its an easy one at that) the day they were notified.
I just want to see them post a patch right away, so that people still have a chance of getting their systems secured before they get rooted.
You might be surprised, given a list of all the IP addresses used to access this forum, or from participants of TrixNet or any public DUNDi groups, how many of them you could exploit and take full control over RIGHT NOW.
By take full control, here are some examples of what could happen to people who dont know any better:
- Botnet could take over your machine and use it to participate in a DDoS attack
- Malicious attacker could erase your entire configuration
- Malicious attacker could use your system to place costly phone calls
- Malicious attacker could shut down your phone system and lock you out, taking down your business. That translates into money.
It's a serious hole, man.
Quote:
There ARE people who
Tue, 07/15/2008 - 9:50pm
Security Vulnerability <> Cheap Sex
Wed, 07/16/2008 - 7:43am
Sorry to disagree but after using various Asterisk aggregations going back to early releases of Asterisk@Home, I'm not sure I have ever seen web access to FreePBX or trixbox compared to having "unprotected sex with crack whores." Nor has there ever been a warning NOT to provide Internet web access to these servers. But, until this vulnerability is addressed, you should definitely put your server behind a firewall with port 80 closed.
What you definitely should not do is rename an index.php file to something that ends in an extension other than .php. For example, index.old.php is hidden (although barely) while index.php.old is extremely dangerous because Apache would process and display a file ending in .old as a mere text file. If it contains passwords or other sensitive information, you're in trouble.
Rather than poking a hole in your firewall for port 80, a safer alternative that we use for web access is to create an on-the-fly SSH tunnel for web access to your web site. For example, issue a command like this using the FQDN of your Asterisk server:
ssh -L 8234:localhost:80 root@yourserver.dyndns.org
Once you've opened this connection, then you can access your web site using a browser on the same computer with a command like this:
When you finish browsing your web site, just shut down the SSH tunnel.
Ward -
I used a bit of
Wed, 07/16/2008 - 8:15am
Ward -
I used a bit of literary license to illustrate a point. I am fairly sure in your writings that you have employed a bit of creative word smithing. It was a bit guttural, however my intention was to make a gross analogy, from your networks perspective the activity is certainly deadly.
I don't care what package it is it makes no sense to expose administrative access to any device to users or God forbid the Internet. I set access lists in every device fro routers to firewalls to the thermostat. Embedded OS's often have exploits. Secure is a design criteria not an afterthought.
Quote:
Nor has there ever been a warning NOT to provide Internet web access to these servers.
I am truly shocked that such a pile of liberal crap would come out of a southern gentleman. Should this warning be authored by the same brain waves who tell me not to bathe with my appliances or use my lawn mower as a hedge trimmer?
Certainly, in many forums the suggestion of not placing the server directly on, or in an open DMZ has made made innumerable times.
Scot
--
Scott
aka "Skyking"
Just a thought you could
Wed, 07/16/2008 - 9:40am
Just a thought you could append the file and add to the top
<?php
die ("OH SNAP NOTHING TO SEE HERE");
?>
sed 1 liner:
sed -i '1i\ <?php die ("OH SNAP NOTHING TO SEE HERE"); ?>' /var/www/html/user/index.php
when I try and open the
Wed, 07/16/2008 - 12:35pm
when I try and open the maint pages in firefox, I get:
Notice: Use of undefined constant SERVERSTATUS - assumed 'SERVERSTATUS' in /var/www/html/maint/modules/01_Home/index.php on line 322
Notice: Use of undefined constant ASTERISKSTATUS - assumed 'ASTERISKSTATUS' in /var/www/html/maint/modules/01_Home/index.php on line 333
Notice: Use of undefined constant ACTIVESIPCHANNELS - assumed 'ACTIVESIPCHANNELS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 160
Notice: Use of undefined constant ACTIVEIAX2CHANNELS - assumed 'ACTIVEIAX2CHANNELS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 168
Notice: Use of undefined constant SIPREGISTRATIONS - assumed 'SIPREGISTRATIONS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 174
Notice: Use of undefined constant IAX2REGISTRATIONS - assumed 'IAX2REGISTRATIONS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 180
Notice: Use of undefined constant SIPPEERS - assumed 'SIPPEERS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 190
Notice: Use of undefined constant ONLINE - assumed 'ONLINE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 190
Notice: Use of undefined constant OFFLINE - assumed 'OFFLINE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 190
Notice: Use of undefined constant ONLINE - assumed 'ONLINE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 200
Notice: Use of undefined constant OFFLINE - assumed 'OFFLINE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 200
Notice: Use of undefined constant UNMONITORED - assumed 'UNMONITORED' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 200
Notice: Use of undefined constant HELPFULLINKS - assumed 'HELPFULLINKS' in /var/www/html/maint/modules/01_Home/index.php on line 338
Notice: Use of undefined constant FORUM - assumed 'FORUM' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 211
Notice: Use of undefined constant RECENTPOSTS - assumed 'RECENTPOSTS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 213
Notice: Use of undefined constant LATESTNEWS - assumed 'LATESTNEWS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 215
Notice: Use of undefined constant HUDLITE - assumed 'HUDLITE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 217
Notice: Use of undefined constant VIDEOTUTORIALS - assumed 'VIDEOTUTORIALS' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 219
Notice: Use of undefined constant DOCUMENTATION - assumed 'DOCUMENTATION' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 221
Notice: Use of undefined constant TRIXBOXSTORE - assumed 'TRIXBOXSTORE' in /var/www/html/maint/modules/01_Home/includes/asteriskInfo_functions.php on line 223
IE just shows a page can't be displayed error.
- best practice rules - why expose?
Wed, 07/16/2008 - 3:56pm
There's been some very good and helpful comment here and we all ( I hope ) are responsible people (most of whom can type better than me!).
Stick to best practice - only expose what you have to, minimise the attack surface.
I can (personally) see little reason to publicly expose anything more than IAX (4569 UDP ?) to a TB box so why expose port 80? - it's like leaving your shiny new iPhone 3g on the table at Starbucks when you go out to the car to get something - in an ideal world it'd be fine, but some people like iPhones so much they'll steal them, some people hate them so much they'll steal them and some people just shouldn't be trusted with that much caffeine coursing through their veins - just keep it in your pocket, take it out admire it at the office (TB on LAN) at home (TB via VPN) - VLAN if practical, change ports, lock down access do what you can. It you have a 24x7 call center with minimum wage staff, they'll get bored and may find a way to browse to you TB - lock it down (you wouldn't leave your iPhone there either, not overnight!).
Remember the only completely secure computer is one with no power, network, disk, display, keyboard, memory etc.
(off my soap box now...sorry...)
(at least you had something to read waiting for Kerry to post - come on guys....!)
J
Since I never place any
Wed, 07/16/2008 - 5:21pm
Since I never place any servers in a compromised position I was posting useful best practice advice. I see that not only was the problem acknowledged it was patched in 48 hours.
That's a great response time.
As I said in my original post, let's focus on the outstanding bugs and getting the current Asterisk and FreePBX stuff rolled into the repository.
Scott
--
Scott
aka "Skyking"
A Note on Security plugs
Wed, 07/16/2008 - 8:10pm
As people bark at trixbox for a week reflect on the following:
* For the period of July 1, 2006, through December 31, 2006
* Windows had 12 severe threats with the total of 39 vulnerabilities fixed in an average of 21 days.
* Mac OS X had 1 severe threat but Apple had an average 66 day turn-around for the entire 43 vulnerabilities reported.
* Red Hat Linux was actually faster than OS X with a 58-day average time to fix a total of 208 vulnerabilities.
* Of those Red Hat threats, 2 were critical and 130 were rated medium severity.
* HP-UX had 98 vulnerabilities and needed an average of 101 days to fix them.
All of the above are PAID FOR products, trixbox is free :)
Don't kill the messenger now that you know about the threat use some of the workarounds and stand by. If a paid product takes up to 101 days and you get what you pay for then the tb team has all the time in the world.
could have been impressive response
Wed, 07/16/2008 - 8:50pm
I would have been more impressed with the response if:
- instead of posting it in a blog where I have to click to read, they had posted the information about a flaw which allows root level on page one of the site. Especially when they had a solution which requires that people go and download the fix it would have been nice to see a large notice on page one.
- when comments and concerns were mentioned on a couple of different threads somebody from Fonality had directed attention to the blog entry. In fact it seems most people, yourself included James, did not seem to have even read the blog. The first mention of the blog was not made on this thread until late this afternoon.
- instead of advertising for training on my maint page there had been a warning advising of a major flaw having been found.
- instead of hyping the upcoming conference in LA they had placed some emphasis on this urgent matter.
- instead of saying the flaw was a 2.6 problem they had mentioned it was also a 2.4 and possibly a 2.2 problem.
It is true the response was quick, but how many people knew about the response? The failure to communicate the response may have allowed some people to be hit with this when had they known about the response they could have avoided the problem altogether. Yes it is everybody’s individual responsibility to secure their system, but a little communication might have helped some people before they had the problem.
Quote:
- instead of
Wed, 07/16/2008 - 10:45pm
Quote:
- instead of advertising for training on my maint page there had been a warning advising of a major flaw having been found.
Come on now, when you go to Sun and Cisco's web site just to name a few do they tell you about new products or do they list security flaws on a big banner? Have some realistic expectations, Cisco has had service compromising problems on core routers and it required reflashing to fix.
Quote:
- instead of saying the flaw was a 2.6 problem they had mentioned it was also a 2.4 and possibly a 2.2 problem.
Are you assuming this or is it fact? I do not know if the systems are vulnerable. Perhaps someone in the user community with those versions would be willing to test and report back results.
You have to have reasonable expectations from free software. I think Jame's post put it in perspective well.
Scott
--
Scott
aka "Skyking"
it is a fact
Wed, 07/16/2008 - 11:05pm
2.4 is vulnerable and it appears that 2.2 is as well. The blog only mentions 2.6. So that comment stands.
As to the first quote of mine you cited I will partly concede that. Keep in mind that is advertising they push to my browser page on my maintenance page not the trixbox.org page. If you can push an ad for me to see when I am managing my system you can also push a critical warning as well.
So out of 5 statements you can refute one and even that I don't totally agree with because just because Cisco does it does not make it good practice.
Like I said, the response was quick, but the communication was not so good. They put the fix out there, but the odds of finding the fix before having the problem were slim. They had the means, but I think you do a dis-service by suggesting they should live down to the behavior of some of these other companies. Why aim so low?
I am realistic. I just thought they could have communicated better. Replying to James' post, I am not killing the messenger. I just think the messenger could have been a little more vocal at a time when the message could have done a little more good.
Quote:
So out of 5
Wed, 07/16/2008 - 11:52pm
Quote:
So out of 5 statements you can refute one and even that I don't totally agree with because just because Cisco does it does not make it good practice.
The first four where all along the same line. I just used Cisco as an example, it's a toss up of who's the worst, probably Sun.
I have very low expectations, I am amazed when any Open Source software works. I am very careful to test before I deploy. Look through my history I have posted on methodologies for developing test plans for deploying Open Source in the enterprise. I am a huge supporter and a big believer.
I consider a little digging the price I pay for free software. So is giving back what I have learned in forums such as these. The flexibility of Open Source is so many orders of magnitude better than any closed source counterpart. I also learn a lot along the way.
To me it's a good deal, and even getting to banter about opinions like this is a great opportunity.
At the end of the day it is all good, and since it is the end of my day I will close with....
Good Night.
Scott
--
Scott
aka "Skyking"
exposing ones self
Thu, 07/17/2008 - 12:33am
If you do a search of Kerry's post you can see he always suggest keeeping TB secured BEHIND a firewall.
There is no reason in the world to expose the box to the outside world NONE.
I think his way to access boxes from outside is to use Hamachi; which I use and it works very well.
All system's can be hacked (If you can get out, someone can get in, never think you are safe)
Best thing to do is ASSUME you will be hacked and to watch for it
READ your logs I spend over 3 hours a day just reading logs.
And I am sorry Scott, but it should matter to you what these newbies put out on the net, that is OUR net they are filling up with traffic, that is our email servers they are spamming
that is our webservers they are hammering with DDOS attacks.
They as the fools who exposed a OPEN source pieced together with who knows what code to the world.
so I guess this thread
Thu, 07/17/2008 - 6:35am
so I guess this thread turned into an argument about who deserves to get hacked, instead of someone posting up a solution.
Nice guys.
I'm running 2.2 and it's hosed. If anyone knows how to fix this without having to reload everything and start from scratch I'd really appreciate it. Otherwise I'm done with this thread. I don't have time to watch people bicker over whether or not someone did something that is considered stupid. I'd much rather see people with the expert knowledge of these systems shrug it off and come up with a valid resolution.
(off soapbox)
The author of the exploit
Thu, 07/17/2008 - 7:10am
The author of the exploit had promised to test our fix before announcing the issue so that he could verify our solution and be able to follow up with our response. Instead he jumped the gun and posted it. He still has not confirmed our fix so we did not roll the fix out to previous versions yet as we wanted to make sure that our fix actually was acceptable. Since I have been out of town this week I haven't really been following this except for knowing that the author has not done his part. Our team is going to have fixes pushed to the other versions today.
Quote:
I'd much rather see
Thu, 07/17/2008 - 7:21am
Quote:
I'd much rather see people with the expert knowledge of these systems shrug it off and come up with a valid resolution.
The solution has been offered 1000's of times. Use a firewall, use a VPN, use access lists.
Even with the patch I would not consider exposing the web interface to the Internet. There is no good reason to do this other than laziness.
Once somebody has access to your system it is impossible to give instructions to fix it. If you did not have the knowledge to secure it I doubt you have the administration skills to repair it.
Quote:
I don't have time to watch people bicker
We are not bickering with you, everyone who participated in the thread agreed with best practices. Why do you have to watch us bicker?
Stop blaming people/places/things and start taking responsibility. What's the deal with reloading? Or don't you believe in backups either?
Scott
--
Scott
aka "Skyking"
I am not blaming anyone
Thu, 07/17/2008 - 7:37am
I am not blaming anyone Scott, but thanks for re-iterating what I've already said regarding my lack of linux knowledge.
I'm just waiting for a solution so I don't have to start from scratch. I'd much rather repair it than just wipe it out and re do everything. Plus...repairing it I'd learn more. And then I can be as cool as you!
I see you're too busy taking the defensive mode to really give a crap...just do us all a favor and not post anything unless you're actually going to contribute something helpful. Simply calling people out and saying "you should have done this or that" doesn't do anything for us now.
You will not learn anything
Thu, 07/17/2008 - 7:47am
You will not learn anything from the patch. You will be able to just do a yum update to close the security hole. That doesn't teach you anything about properly securing a system. Virtually every guide on installing trixbox all say you should never have it exposed on the public internet. Most of these systems do not get regular updates and even if we had fixed this six months ago, over 99% of the systems out there would not have been updated. So yes, while it is a code problem that is easily fixed, the risk should be mitigated by following common sense practices when deploying systems. A phone system is usually the single most mission critical component in any business and should be treated as such and be well protected.
Quote:
Thu, 07/17/2008 - 7:57am
Quote:
I'm just waiting for a solution so I don't have to start from scratch.
If you have been compromised there is no solution. If you are running a previous version and waiting for a patch so you can place it on the Internet and wait until the next exploit is discovered.
Quote:
repairing it I'd learn more. And then I can be as cool as you!
First of all I am hardly cool, I am an old fat guy. Now Bubba he's cool!
I would never bother repairing a compromised system, it's too much work. Learning is the epitome of cool.
Quote:
I see you're too busy taking the defensive mode to really give a crap...just do us all a favor and not post anything unless you're actually going to contribute something helpful.
Who am I defending? I am advocating best practices for security. Until everyone gets it I will beat them over the head with it until they are senseless. Since I have contributed volumes on how to configure networks and security along with showing my hard found tricks for procuring enterprise class firewalls for pennies on the dollar, I am trying to do my part.
The worst part is trixbox comes with a VPN client that works fairly well (Hamachi) and there are many articles on how to use it. There is even a setup script. So if the urge comes over you to remote administer your phone system you have a way to do it.
When someone admits to not having secured their box in favor of administration it speaks volumes to their overall system admin skills. If they knew what they where doing they would have had a VPN in place prior to installing the trixbox server.
Scott
--
Scott
aka "Skyking"
fix
Thu, 07/17/2008 - 7:58am
We have a simple fix that should solve the problem, but its not fully tested. I am going to paste it below, and if people can verify that it fixes the issue, we will get it out as an update ASAP. Its a simple fix, to just filter that variable.
Diff follows:
Index: branches/2.6.1/tbm-GUIcore/tbm-GUIcore/maint/index.php
===================================================================
--- branches/2.6.1/tbm-GUIcore/tbm-GUIcore/maint/index.php (revision 927)
+++ branches/2.6.1/tbm-GUIcore/tbm-GUIcore/maint/index.php (revision 928)
@@ -14,7 +14,7 @@
apache_setenv('QUERY_STRING',$_SERVER["QUERY_STRING"] = addslashes(strip_tags(urldecode($_SERVER["QUERY_STRING"]))));
apache_setenv('REQUEST_URI',$_SERVER["REQUEST_URI"] = addslashes(strip_tags(urldecode($_SERVER["REQUEST_URI"]))));
-$_POST['langChoice'] = str_replace(array('/', '\\','.'),'',$_POST['langChoice']);
+if (isset($_POST['langChoice'])) $_POST['langChoice'] = str_replace(array('/', '\\','.'),'',$_POST['langChoice']);
ini_set("error_reporting","E_ALL & ~E_NOTICE");
//echo phpinfo();
Index: branches/2.6.1/tbm-GUIcore/tbm-GUIcore/user/index.php
===================================================================
--- branches/2.6.1/tbm-GUIcore/tbm-GUIcore/user/index.php (revision 927)
+++ branches/2.6.1/tbm-GUIcore/tbm-GUIcore/user/index.php (revision 928)
@@ -13,7 +13,7 @@
apache_setenv('QUERY_STRING',$_SERVER["QUERY_STRING"] = addslashes(strip_tags(urldecode($_SERVER["QUERY_STRING"]))));
apache_setenv('REQUEST_URI',$_SERVER["REQUEST_URI"] = addslashes(strip_tags(urldecode($_SERVER["REQUEST_URI"]))));
-$_POST['langChoice'] = str_replace(array('/', '\\','.'),'',$_POST['langChoice']);
+if (isset($_POST['langChoice'])) $_POST['langChoice'] = str_replace(array('/', '\\','.'),'',$_POST['langChoice']);
ini_set("error_reporting","E_ALL & ~E_NOTICE");
session_start();
Apparently that didnt work
Thu, 07/17/2008 - 10:12am
Apparently that didnt work so here's another method:
(put this near the top of index.php or you could put it in includes/functions/functions.php where is where the exploitable code is)
$langArray = array('english','estonian','french','portuguese','spanish','swedish','turkish');
if (isset($_POST['langChoice'])) {
$_POST['langChoice'] = (isset($langArray[$_POST['langChoice']])) ? $langArray[$_POST['langChoice']]:"";
}
that second method doesn't
Thu, 07/17/2008 - 10:45am
FIX v2.2.3 Tested and Working
Thu, 07/17/2008 - 10:58am
This fix will eliminate the language POST security vulnerability by adding an array of selectable language types only. This is not the most efficient way but it works and keeps your language selection in working order.
This works for the /user/ web front of the trixbox system version: v2.2.3.
edit
/var/www/html/user/includes/functions/functions.php
with your favorite editor and add this code:
$langArray = array('english','estonian','french','portuguese','spanish','swedish','turkish');
if(isset($_POST['langChoice']))
$i=0;
$unsecChoice = $_POST['langChoice'];
while ($i<count($langArray)){
if (preg_match("/^".$langArray[$i]."$/",$unsecChoice,$langFound)){
$langChoice=$langFound[0];
break 1;
}
$i++;
}
inbetween (line numbers are estimates):
(72): $sessionFile = 'cache/sessionsFile.txt';
and
(74): if(isset($_POST['langChoice'])){
after you have added that, edit the line and put a # in front of it:
before(76): $langChoice = $_POST['langChoice'];
after(76): #$langChoice = $_POST['langChoice'];
Then change:
(74): if(isset($_POST['langChoice'])){
to
(74): if(isset($langFound[0])){
So the whole thing looks as follows:
$sessionFile = 'cache/sessionsFile.txt';
$langArray = array('english','estonian','french','portuguese','spanish','swedish','turkish');
if(isset($_POST['langChoice']))
$i=0;
$unsecChoice = $_POST['langChoice'];
while ($i<count($langArray)){
if (preg_match("/^".$langArray[$i]."$/",$unsecChoice,$langFound)){
$langChoice=$langFound[0];
break 1;
}
$i++;
}
if(isset($langFound[0])){
#$langChoice = $_POST['langChoice'];
$_SESSION['trixbox_Language'] = $langChoice;
I say again, it isnt the most efficient way but it works for me.
wow I havent had enough
Thu, 07/17/2008 - 11:39am
wow I havent had enough caffeine this morning. try this:
(now using the pre tag, because code tag sucks)
$langArray = array('english','estonian','french','portuguese','spanish','swedish','turkish');
if (isset($_POST['langChoice'])) {
$_POST['langChoice'] = (in_array($_POST['langChoice'],$langArray)) ? $_POST['langChoice']:"english";
}
i've tried all the above and
Thu, 07/17/2008 - 12:23pm
the user part works now, but
Thu, 07/17/2008 - 12:30pm
It shouldn't be any
Thu, 07/17/2008 - 1:26pm
It shouldn't be any different for maint/index.php, and it works for me.
I dont know why you are having an issue with ARI or that javascript error.
The one thing I can think of that can mess things up is if your language got set to nothing, and that can be fixed by deleting the file in maint or user "/cache/sessionsFile.txt" and then clearing your browser's session cookie immediately (close all open windows or other methods).
First I tried what grey
Thu, 07/17/2008 - 1:50pm
First I tried what grey posted up initially, then I changed things back they were (as I did every time it didn't work so I could start fresh)...then I tried modifying the code just like you posted up Adrian. That didn't work so I tried grey's revision. The USER home page then displayed correctly, however getting errors when logging into ARI and the CRM link fails.
I added grey's revised code to the functions.php pertaining to maint just like i did for user, and that didn't work.
I then deleted the sessionsfile.txt from the cache directories of both user and maint...and the graphics are there for user (still can't get ARI to work) but graphics are gone for maint...plus the sessionsfile.txt files no longer returned.
Just a small kudo to this
Thu, 07/17/2008 - 2:23pm
Just a small kudo to this thread. this is how community development is suppose to work.
This sounds like the issue I
Thu, 07/17/2008 - 2:42pm
This sounds like the issue I had and it drove me absolutely bannana's for a whole day trying to figure out where I F'd the whole thing up. You need get both of those sessionText.txt files in user/cache and maint/cache deleted and then make sure you've got any cookies cleared. If any of those three things remain, the other 2 will come back and you'll still be screwed.
We are rolling the RPM for the update with this fix in it.
Also I just wanted to add that this code and a lot (most .. all ..) of other code is going to get tossed or at least heavily rewritten soon. There's a lot of issues in the code and right now its like the proverbial dam with cracks in it, and I only have two hands. Security, stability, speed and features are all high considerations (as apposed to 'just get something working asap even if it results in a pile of spaghetti code').
I would like to point ou
Thu, 07/17/2008 - 2:57pm
I would like to point ou that the same issue is in the /maint/ side aswell to do with language selection. I have just built a working exploit that uses the language selctor on /maint/ BUT because it is passwod protected it is alot less crucial. It could be modified to potentially give local root esculation aswell.
Cheers
timmeh4371:
They get
Thu, 07/17/2008 - 2:59pm
timmeh4371:
They get generated by the php backend so deleteing them essentialy makes the system think you havent been on it before and sets things to default (in terms of the web content) for you. Like language selection is saved in the sessions text files just for ease of use so you dont have to keep changing the language every new page load.
okay I see it get created
Thu, 07/17/2008 - 3:06pm
thanks Greywire
Thu, 07/17/2008 - 3:18pm
Yes I can attest to the numerous issues in the code!
A rewrite would be nice to clean up the notice and info errors as well as all the other coding.
Thanks for the good work and chiming in and getting it working.
Paris
PS Why were the registered users not sent an email about this needed update / change? The blog is great if you come regularly. I can't too many other things to do. An email would have helped, I just happened to catch on to this looking for another issue I'm trying to solve.
Thanks
We are trying to get out a
Thu, 07/17/2008 - 6:48pm
We are trying to get out a patch that is foolproof (IE a simple script).
What we just found right now, is that you need to not only delete those two sessionText.txt files in both maint and user /cache, and the cookie, but you also need to clear the sess* files in /tmp. The exploit will put its crap in all those places.
With the code fix in place in both maint/index.php and user/index.php you cant get anything funky into those sessions or cookies. But you have to get rid of them all first. A lot of the code goes all wobbly if something strange is in that langChoice variable.
I am guessing this is all due to the code first implementing its own session management, then at some point started using php4's built in sessions but still using the old code too. And at no point was any input filtering implemented.
Yes, there's lots of cruft in the code. Errors and warnings from just plain lazy coding. Overly complex spaghetti code. Etc etc etc.
Fix for CE
Thu, 07/17/2008 - 9:04pm
the fix does what I
Fri, 07/18/2008 - 6:40am
the fix does what I described here. You may not be able to run that script (it replaces the index.php files so that might mess up other code in 2.2), but, you can take the bit of code and stick it in the index.php file near the top, and you can delete the sessions files by hand.
Do this:
Insert this code near the top of user/index.php AND maint/index.php:
$langArray = array('english','estonian','french','portuguese','spanish','swedish','turkish');
if (isset($_POST['langChoice'])) {
$_POST['langChoice'] = (in_array($_POST['langChoice'],$langArray)) ? $_POST['langChoice']:"english";
}
Then you need to delete user/cache/sessionText.txt AND /maint/cache/sessionText.txt AND you need to delete the sess_* files in /tmp AND finally clear your browser's session cookies. If you don't do all of these the exploit wont be removed.
Member Since:
2007-11-20