Site and Server Security

Re: Vulnerability Summary CVE-2008-3296

Quote:


davidl2 wrote:
Yes - I think Steve's correct.

But we'll need a none-HTML PUrifier solution for 1.0 as well.


Good point

Report
Topic


Re: Vulnerability Summary CVE-2008-3296

Yes - I think Steve's correct.

But we'll need a none-HTML PUrifier solution for 1.0 as well.

Report
Topic


Re: Vulnerability Summary CVE-2008-3296

Quote:


skenow wrote:
Just wondering - is this something we can address with HTMLPurifier?



What do you mean? The security fix?
I thought that was what the purifier was for. Maybe even extend the purifier and purify the _GET _POST and _COOKIE requests, or something like that.

Report


Re: Vulnerability Summary CVE-2008-3296

Just wondering - is this something we can address with HTMLPurifier?

Report


Re: Vulnerability Summary CVE-2008-3296

There is a bit of a problem with our fix - once in system admin, all the functions redirect to modules/system/admin.php.. I think this is also the login problem on the latest revision.

Report


Re: Vulnerability Summary CVE-2008-3296

Ah glad that DJ's used Vaughan's fix - or something rather like it.

Sadly seemed to forget to credit the source for this.... but I'm sure that was just a slip of memory.

Report


Re: Vulnerability Summary CVE-2008-3296

  • 2008/7/26 17:48:49
  • Tom

Yup and should you need to give them group admin access without being able to modify the main admin group you could use Kaotik Group Manager module.

Report


Re: Vulnerability Summary CVE-2008-3296

For sites you run for clients, I suggest creating another user group that gives them the admin access they need and not placing them in the Webmasters group. Then you can set the version checker to only be visible to the webmasters and not to the client admins. 1.1 has a new feature that makes this easier to do - in the past the Groups module served this purpose.

Report


Re: Vulnerability Summary CVE-2008-3296

Quote:

I agree with this, but it should also be a little discrete for those running sites for clients.



A valid point - perhaps a message in the final screen of the installer...

"To keep updated with latest security releases - please sign up here"

And of course a link to community (and local community sites) for general news

Report


Re: Vulnerability Summary CVE-2008-3296

  • 2008/7/26 12:18:44
  • Tom

Quote:

I think you are giving to much atention to this. If an hacker gains admin access it could use the blocks to inject php code so Why even care in protecting this? And talking about modules, there is 0 protection for sql injection in their admin areas. Best step is done in protector setting admin acess to specific IP's.



I respectfully disagree, a security risk is a security risk regardless of how small or large it is, likely or unlikely.

Quote:

On the idea of a public security mailing list, I think we can and should build this into the core - our version checker gives us the ability to feed information about version updates to all users. This could be expanded to include hot fixes like this one. This would give us much better coverage of the install base than a mailing list would - people might not subscribe, email addresses might change, the webmaster might change, but an active site will always be able to use the version checker.



I agree with this, but it should also be a little discrete for those running sites for clients.

Report


Re: Vulnerability Summary CVE-2008-3296

  • 2008/7/26 12:12:58
  • Will

Amen! @ Vaughan

Report


Re: Vulnerability Summary CVE-2008-3296

Sorry, I miss this thread.

We already have a function in the core to fix this. I add this function when I created the content manager but perhaps we can merge both to make a better solution.

function StopXSS($text){ if (!is_array($text)){ $text = preg_replace("/\(\)/si", "", $text); $text = strip_tags($text); $text = str_replace(array("'","\"",">","<","\\"), "", $text); }else{ foreach ($text as $k=>$t){ $t = preg_replace("/\(\)/si", "", $t); $t = strip_tags($t); $t = str_replace(array("'","\"",">","<","\\"), "", $t); $text[$k] = $t; } } return $text; }


This is the function and to use it just do this:

if (isset($_POST['fct'])) { $fct = StopXSS($_POST['fct']); } if (isset($_GET['fct'])) { $fct = StopXSS($_GET['fct']); }


or make this to filter all POST and GET variables

if (!empty($_POST)) foreach ($_POST as $k => $v) ${$k} = StopXSS($v); if (!empty($_GET)) foreach ($_GET as $k => $v) ${$k} = StopXSS($v);



If you like my work you can Donate
Report


Re: Vulnerability Summary CVE-2008-3296

We can only set the example and work for the best

Report


Re: Vulnerability Summary CVE-2008-3296

Quote:

phppp wrote:

The "vuln" has been reported and discussed a couple of times and the conclusion made by XOOPS dev team at the moment was that it is not an valid vuln thus won't fix.

However, to keep XOOPS elegant, the code will definitely be improved in future releases.



typical....

Report


Re: Vulnerability Summary CVE-2008-3296

Quote:

On the idea of a public security mailing list, I think we can and should build this into the core



Seconded - this is a feature that *should* be added even at this stage.

Report


Re: Vulnerability Summary CVE-2008-3296

Any opportunity we have to make any part of the core more secure I think is worth the effort to do so. Any single vulnerability may not appear to present a high risk, but we have seen otherwise. The 'minor' weakness may be leveraged in combination with another 'minor' weakness and present a serious problem. Kudos for the quick response to all these!

On the idea of a public security mailing list, I think we can and should build this into the core - our version checker gives us the ability to feed information about version updates to all users. This could be expanded to include hot fixes like this one. This would give us much better coverage of the install base than a mailing list would - people might not subscribe, email addresses might change, the webmaster might change, but an active site will always be able to use the version checker.

Report


Re: Vulnerability Summary CVE-2008-3296

but we've seen constantly how mikhail gained admin privileges and then assigned users to admin group.

now i understand that this exploit is only possible if the user is admin, but if such a user was given admin, then it would be possible.

cracking is not just about hacking code and exploiting vulnerabilities to gain access, crackers use various tactics (call it social hacking if you must) where they become friendly with users in order to gain trust!! but as soon as their guard is down.. hey presto.

and yes if a user has gained admin, then that is a whole different issue of security.. and yes we should try to improve sanitation for admin functions & queries also.

if it's not important in admin, then it's not important in the installer either, so why fix security issues with the installer when that is only used to install and then should be removed from the server??

in essence, we should strive to remove all issues whether they are directly exploitable or whether they *could* potentially be used to exploit under certain conditions.

something with potential, could in future become a problem.. if we remove that potential, we save ourselves more work in the future if that potential escalates.

At the end of the day, Protector module is a must have, but users are wholly reliant upon it, and this should not be the case, protector module should only be a secondary protection measure, the core *must*/*should* always be the primary means of protection.*/

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!
Report


Re: Vulnerability Summary CVE-2008-3296

Trabis - you are quite right, but it doesn't harm to make sure things are as secure as possible.

As for module admin - this is something we need to address with future Impress-specific modules... perhaps some way to limit what they are required to access would be a useful area to look at.

Block abuse: I agree. This is an area that JMorris brought to Skalpa's attention prior to his need to move away from core development, so yes - it's an issue which has been of concern for sometime.

I believe that Vaughan's work on Purifier will give some possibilities on how this can be prevented from abuse in 1.2 onwards.

Report


Re: Vulnerability Summary CVE-2008-3296

I think you are giving to much atention to this. If an hacker gains admin access it could use the blocks to inject php code so Why even care in protecting this? And talking about modules, there is 0 protection for sql injection in their admin areas. Best step is done in protector setting admin acess to specific IP's.

The essencial is keep admin access Secure and being that the first barriage we should not care about the rest.

Report


Re: Vulnerability Summary CVE-2008-3296

Yes. Good thinking - I guess variations of both fixes would possibly apply in those cases?

Report



 Top