Community Forums

by **Daniel** » Tue Sep 06, 2011 4:13 pm

I have just become aware of a security problem with OpenCart 1.5.x and all previous versions.

The fix is here:

http://code.google.com/p/opencart/source/detail?r=577

you need to replace your library cache file.

system/library/cache.php

with

cache.php: (1.16 KiB) Downloaded 2597 times

So far all it does is overwrite files in your site with blank ones.

I'm going to release a version 1.5.1.2 with the fix included.

sorry about this guys. I'm really kicking myself for not finding this sooner.

by **extigo** » Tue Sep 06, 2011 4:36 pm

Maybe I doesn't understand correctly but is this also needed for the version 1.4.9.x and lower?

by **Daniel** » Tue Sep 06, 2011 4:53 pm

yes.

i have been testing this hack though and can;t seem to pull it off.

i'm still testing to see what has actually happened.

by **mkh** » Tue Sep 06, 2011 5:06 pm

Daniel wrote:I'm going to release a version 1.5.1.2 with the fix included.

So, I can still use my 1.5.1.1 if using this fix, the cache.php ?

Thanks.

by **Daniel** » Tue Sep 06, 2011 5:07 pm

ok possible false alarm.

i just checked the code and their is no way this could happen.

it was reported here:

http://vickigroup.wordpress.com/2011/09 ... -versions/

they reported it today.

can anyone else please try to see if they can get this hack to work.

by **JAY6390** » Tue Sep 06, 2011 5:32 pm

I can see where they are coming from with the unsanitized data, but it shouldn't actually work, and I can't get it to replicate. That said, it is possible for someone to fill your cache folder with loads of useless files. Say for example I put country_id=1.1.1.1.1.1.1.1 That would still make a cache file for country id 1 but the wrong cache name. This should be stemmed to just 1 using (int) like in the query in the localisation/zone model file

by **Xsecrets** » Tue Sep 06, 2011 6:07 pm

regardless I don't think the problem is going to be in the cache file itself, but in other files that call it using unsanitized data.

by **Xsecrets** » Tue Sep 06, 2011 6:26 pm

I couldn't get it to work either, though I suppose that for this particular file you should sanitize the get by calling it with an int which would kill the attack vector, and then for good measure you could check to make sure data is actually returned before you call the cache set.

by **grgr** » Wed Sep 07, 2011 2:15 pm

It very much works and allows you to overwrite files and take the site down. I've tested it on on one live web server running a default(ish) install of 1.5.1.1.

by **dony_b** » Wed Sep 07, 2011 2:38 pm

So whats it gonna be ?

Update the cache.php file or not ?

by **JAY6390** » Wed Sep 07, 2011 2:43 pm

There's no reason you can't update the cache file, but it should be the data input that's sanitized IMO

by **Xsecrets** » Wed Sep 07, 2011 3:13 pm

grgr wrote:It very much works and allows you to overwrite files and take the site down. I've tested it on on one live web server running a default(ish) install of 1.5.1.1.

can you explain exactly how you managed to make it work, because as reported it very much does not work. If you don't want to post in in the open please PM me.

by **grgr** » Wed Sep 07, 2011 9:12 pm

by **Daniel** » Thu Sep 08, 2011 2:43 am

grgr wrote:It very much works and allows you to overwrite files and take the site down. I've tested it on on one live web server running a default(ish) install of 1.5.1.1.

can u you pm me this hack aswell?

by **Xsecrets** » Thu Sep 08, 2011 3:46 am

I was able to get it to write files with additional testing, but I could not make it overwrite files. On my setup the %00 killed it, but from other claims I'm guessing it works on some configurations.