This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » Developer » Integer overflow vector : "high risk...

Integer overflow vector : "high risk : system compromise" ?

Integer overflow vector : "high risk : system compromise" ?

Thursday 25 October 2012 4:57:08 pm - 10 replies


I did a security scan on my local eZ installation recently and got some (false?) positives marked as "high risk: system compromise". The issue called integer overflow vector concerns the event calendar and is triggered with urls like this:

I really don't know what to think about this. Could be a false positive as well, but I would appreciate some advisory from eZ developers.

By the way: is there any "official" way for reporting security issues?

Many thanks in advance.

Friday 26 October 2012 12:50:53 pm


in order to know if it's a false positive or not, could you tell us what "integer overflow vector" means for your security scanner ?

Regarding the official way for reporting security issue, that's a good question. I've just had a look into JIRA and it seems that it's not yet configured to handle a security issue. I mean, such an issue has to be hidden as soon as it's posted and should never be public until it get fixed by the engineering team. So something has to be done on eZSystems' side... (ping Bertrand & Nicolas ?)



Friday 26 October 2012 3:52:18 pm

@Horts - did you try accessing that url directly via the browser? What results did you get?

 I tried it with ezp 4.6.0, using teh ezflow design, and saw nothing special in either the php/apache/eZ logs or in the page output...

Sunday 28 October 2012 9:30:34 am

What security scanner are you using?

Sunday 28 October 2012 3:21:02 pm


the eZ Installation is a ce 2012.6 with ezflow and the issue arises if an event calendar object is published.

Wednesday 31 October 2012 12:06:26 pm

A little more investigation

- using skipfish 2.09b, with the complete dictionary

- testing against ezp 4.6 (ezflow design) and 2012.6cp (demo design)

- after creating an event calendar with an event inside it

- telling skipfish to examine only the paths which are below the event calendar


a) skipfish seems to give imprecise error messages.

F.e. there are some php fatal errors in the logs, not sure exactly about what url makes them popup (or if it's just a race condition going on, as they seldom happen), such as

[31-Oct-2012 10:59:43 UTC] PHP Fatal error:  require() [<a href='/manuals/php5/function.require.html'>function.require.html</a>]: Failed opening required 'extension/ezperformancelogger/classes/ezperflogger.php' (include_path='.;./lib/ezc;.;D:\htdocs\phpxmlrpc\trunk\xmlrpc\lib;D:\htdocs\ezc\releases\ezcomponents-2009.2.1;D:\htdocs\Pear\pear;D:\htdocs\phpunit;D:\htdocs\php-code-coverage') in D:\htdocs\ezp\installs\ezpublish-4.6.0-ent\autoload.php on line 106

These errors are not flagged as "high impact" by default by Skipfish, unless php is configured with error_display=On (which you should not have on prod servers anyway).

But if I test with display_errors=On, Skipfish will flag the page sending back such an error message as "Query injection vector" with "Memo: response suggests arithmetic evaluation on server side (type 2)" - which to me really makes no sense...

Also if I take the URL which Skipfish says it has used to get that "high impact" error, and paste it into the browser, I do not get back a php fatal error, but a plain "module not found" error, with no information leak whatsoever.

The analysis is ongoing...

Modified on Wednesday 31 October 2012 12:08:04 pm by Gaetano Giunta

Wednesday 31 October 2012 3:54:49 pm

Further results, after letting skipfish iterate for over 3h30mins on the same "path":

- no trace of issues above security level "low"

- all php error messages are related to require() failures (plus some warnings about race conditions when rotating log files. that is known and harmless)

- all require() call failures come from extensions which are symlinked into the ezp install - this is actually a windows server, and the type of link used is "junction"

- skipfish seems to be quite confused from the errors: it classifies them with a lot of different codes / memos

- Michal Zalewsky, author of skipfish (whom I contacted by mail) also seems to think that the problem is related to app. instability (

This leads me to the following conclusions:

- php support for junctions on windows might be a little flaky. I will rerun the same test tonight, after having replaced the junctions with actual "real" directories

- the error you mention was most probably a false positive - if you still have the original report available can you zip it and send it to me to be 100% sure?

Monday 05 November 2012 1:29:40 pm

Hi thanks for the replies.

There is definitely no windows server involved. 

I ran another skipfish scan on the same(!) eZ installation (on ubuntu server, display_errors=Off) and got some high risk errors again, this time: "PUT request accepted" and "Format string vector" . The scanner version is 2.02b. 

I have the report of this test. To which mail address do you want me to post it?

Monday 05 November 2012 6:42:10 pm

gg at ez dot no

Thursday 08 November 2012 3:34:06 pm

BTW, interesting to ALL forum members: the possibility to submit a security issue to the bug tracker has been restored.

Now on, you will see a "security" field when creating an issue. If set, only the issue creator (and the security team at eZ) will be able to see the issue.

Modified on Thursday 08 November 2012 3:39:43 pm by Gaetano Giunta

Thursday 08 November 2012 3:46:31 pm

Quote from Gaetano Giunta :

BTW, interesting to ALL forum members: the possibility to submit a security issue to the bug tracker has been restored.

Now on, you will see a "security" field when creating an issue. If set, only the issue creator (and the security team at eZ) will be able to see the issue.

Well done


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from