Re: Security Patch

[loba]

Hi,

I just recieved an email asking me to patch up the BTS files by replacing certain code, and i realised that my code was a bit different from the one listed...

code found in my oscmax -->
e.g.
<?php if ($javascript) { require(DIR_WS_JAVASCRIPT . $javascript); } ?>

code that was supposed to be replaced -->
e.g.
<?php if ($_javascript) { require(DIR_WS__JAVASCRIPT . $_javascript); } ?>

Should i be replacing the code since i couldnt find any code the resembles that except for the one i showed? or should i remove the underscore?

[michael_s]

Hi,

Give it a try and replace them. It should not matter. If you run into problems, come back and let me know.

[loba]

ok thanks mate!

[paulM]

Hi msasek,

thanks for the security update!

I'm not sure how the exploit exactly works, but would you agree that this vulnerability would not have existed if register_globals would be off? (and the script would have been register_globals off compatible of course)

Paul

[bdneuman]

msasek:

Can you give me an idea of how this code can be exploited?

I have and continue to modify my site w/ contrib's as well as my own tweaks (including added javascripts). I would just like to have an idea of what to look out for to avoid unknowingly opening up another security leak as I am editing the code.

Thanks in advance for the info.

[dreamscape]

I'm not sure how the exploit exactly works, but would you agree that this vulnerability would not have existed if register_globals would be off? (and the script would have been register_globals off compatible of course)

Hi Paul. Your intuition is correct. This exploit and the vast majority of exploits for osCommerce and its contributions only work because they exploit the scripts reliance on register_globals.

I'm not sure why the OSC team did not make MS2 register_globals OFF compatible (or better yet require that it be off). It is actually not that difficult to do. Not to bash the team or anything, but over the years it has become pretty apparent that security is not among their top concerns.

[swdave]

I recommend you put an .htaccess file in the templates directory to deny direct access to any php files and then define in application_top any variables used by the template code.

//Protection application_top
$javascript = '';
$content = '';
$content_template = '';
$boxLink = '';
etc...

.httaccess in templates dir

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

[bdneuman]

I recommend you put an .htaccess file in the templates directory to deny direct access to any php files and then define in application_top any variables used by the template code.

//Protection application_top
$javascript = '';
$content = '';
$content_template = '';
$boxLink = '';
etc...

.httaccess in templates dir

<Files *.php>
Order Deny,Allow
Deny from all
</Files>

Michael?

[paulM]

Michael?

I'm not Michael, but I quite sure he will agree with swdave's ideas Actually it's very likely that the next BTS version will include exactly that security improvements.

Also it seems wise to add the .htaccess file (as above) to most other osC folders that don't need direct access too.

[bdneuman]

Michael?

I'm not Michael, but I quite sure he will agree with swdave's ideas Actually it's very likely that the next BTS version will include exactly that security improvements.

Also it seems wise to add the .htaccess file (as above) to most other osC folders that don't need direct access too.

Forgive my noviceness, but you just put the variable in application_top to make the initial definition? Do you remove any of the variables from the various templates files then?