[Pmwiki-users] Security problem of php, is this problem in pmwiki too?

Patrick R. Michaud pmichaud
Thu Dec 16 07:57:03 CST 2004

On Thu, Dec 16, 2004 at 11:25:43AM +0100, Albi Rebmann wrote:
> I read bout php security holes: 
> http://www.hardened-php.net/advisories/012004.txt
> Now my question is, is this a problem to pmwiki too?

Any script can have security holes, not just PHP scripts.  Perl gives
a cgi-bin programmer even *more* rope with which to hang himself...

But I'll briefly address here the vulnerabilities from the article above.

[01 - pack() - integer overflow leading to heap bufferoverflow ]
[02 - unpack() - integer overflow leading to heap info leak ]

None of PmWiki's scripts use the pack() or unpack() functions.

[03 - safe_mode_exec_dir bypass in multithreaded PHP ]

This vulnerability only affects installations where someone can
affect the name of directory in which the script is running.  
PmWiki always executes from the pmwiki installation directory, 
so is not susceptible to this vulnerability.

[04 - safe_mode bypass through path truncation ]

PmWiki doesn't rely on safe_mode for any of its security.

[05 - path truncation in realpath() ]

This vulnerability only exists where user-supplied data is being used 
to construct filesystem path names.  In PmWiki, the only user input
data used to do this are the names of groups and pages.  Since these
names are automatically "sanitized" by PmWiki to contain only
alphanumeric characters, hyphen, and periods, an attacker cannot
effectively exploit this vulnerability to access other portions of
the filesystem.

[06 - unserialize() - wrong handling of negative references ]
[07 - unserialize() - wrong handling of references to freed data ]

PmWiki does not use unserialize(), or any of PHP's serialization

Hope this helps,


More information about the pmwiki-users mailing list