Hi Nicolas, please can you give us some more info about this issue? Exploiting this bug the eZ instances can be blocked, or data can be modified, restricted data could be fetched in search results?

thanks in advance,

Hi Nicolas,

With "3.7 to 4.2", does that mean it includes any version of 4.2 also? That require the patch?

Thanks Robin

Never mind Resolved in 4.2.x and 4.1.x.

For anyone who reads my previous comment, you need to apply the patches to 4.1 and 4.2 also. I got confused. The article Nicolas refers/links to cleary states applying the patches to those versions.

-- Robin

It doesn't look like these issues were fixed in svn, will the fixes land in svn and in which timeframe?

See http://pubsvn.ez.no/websvn2/log.p...ancedsearch.php&rev=0&isdir= and http://pubsvn.ez.no/websvn2/log.p...earchengine.php&rev=0&isdir=

Thanks! This can also be applied into 4.0.x.

Deni

Kristof Coomans: As normal we publish the fix before we commit to svn, something you know very well. Normally it will be in svn soon.

Modified on Friday 26 March 2010 10:11:39 am by André R

Hi Nicolas, please can you give us some more info about this issue?

+1

@Andre: "something you know very well". No need for blaming me that way, I am just asking for information. I can't know (unless it's documented somewhere, if so please point me to the link) what the current policies are because there are no more maintenance releases, and previously security fixes were committed right after the maintenance releases came out.

Hello everyone,

The original blog post was updated, answering all your questions, bringing combined patches along with installation instructions : http://share.ez.no/blogs/ez/security-advisory-promptly-patch-your-ez-publish-instances

Cheers,

Hi everybody!
We think that adding the function "generateSQLINStatement" to the dbInterface class, this patch could be applied (manually) to 3.9.X versions too. We have tested it in two sites and everything is still searching . !
It would be good to have more information or an example about how to exploit the vulnerability, to check if it is fixed now in those/all versions, although I understand to give this information is a big security risk
Best regards.

From what I can make out of the patches this seems like a straightforward SQL injection via the SearchSectionID GET parameter. mysql_query() doesn't support multiple queries so you can't do things like

mysql_query( "SELECT ...; UPDATE ezuser ... " );

so you are a bit better off with MySQL, but you can still insert things like subqueries, etc. pg_query() on the other hand does support making multiple queries making it trivial to gain admin access.

Ole

I found the 4.1 security patch applies smoothly against a 3.10.x site. Could eZ please confirm that this does however correctly secure a 3.10.x site?

The arguments of the eZDBInterface::generateSQLINStatement() method have slightly changed between the 3.10 and 4.0 series, so applying the patch on 3.10 will probably give unexpected results.

I guess you can correct it easily for 3.10 installations though, by removing the 4th argument (false) to the generateSQLINStatement() calls in the patch. I did not test this myself, so use with care.

Modified on Monday 29 March 2010 8:13:16 am by Kristof Coomans

Thanks Kristof, search still works fine without that 4th argument so I'll touch wood and run with that

Hello,
is it safe to simply disable the entire search module?

like this:

[SiteAccessRules]
Rules[]=access;disable
Rules[]=module;content/search

Thanks,
Norbert

Or just advanced search?

[SiteAccessRules]

Rules[]=access;disable

Rules[]=module;content/advancedsearch

Modified on Tuesday 30 March 2010 6:08:29 pm by Steven E Bailey

Hello,

Can you confirm us that those patches are bundled on eZ 4.3 version?

Thanks!

Hello,

Can you confirm us that those patches are bundled on eZ 4.3 version?

Thanks!

Of course!

Paul