full-disclosure - Critical PHP bug - act ASAP if you are running web with sensitive data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed Mar 29 08:17:18 2006
From: tonu at jes.ee (Tõnu Samuel)
Subject: Critical PHP bug - act ASAP if you are running
	web with sensitive data

Jasper Bryant-Greene wrote:

> My point is, can you think of a logical reason why html_entity_decode 
> would be run on user input? I'm sure some idiot is doing it (and 
> therefore this is a security issue, though not exactly critical), but 
> I don't think I can think of a reason why it would be done.
>
> Why would you want to decode HTML entities given by a user? The 
> opposite (encode their input into HTML entities) is the usual approach...

Ok, this "critical" is my fault. Seeing memory dump of other user data 
seems serious enough to me and I suspected it might affect different 
functions despite this one. Now when we know more, I agree that it is 
less critical than suspected by me. Still it is a problem and as subject 
told: "if you are running web with sensitive data". Malicious user can 
upload new script and see what others are doing. In most cases not so 
critical as I assumed but still bad enough and I really expect to see 
announcements for such problems faster and patches to come out (I mean 
RPM-s this time). Right now my systems are unprotected till I start to 
make packages myself or Novell is going to make one. Three weeks is too 
much. And what about PHP 4.x and 5.0 users?

    T?nu