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] [day] [month] [year] [list]

Message-ID: <2f6cb7b40603292133y58caabcbyfa477b98bd3175cc@mail.gmail.com>
Date: Thu Mar 30 06:33:52 2006
From: nocfed at gmail.com (nocfed)
Subject: Critical PHP bug - act ASAP if you are running
	web with sensitive data

On 3/29/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> On Wed, 29 Mar 2006 02:40:49 CST, nocfed said:
> > Right, that is a vector that nobody knows about unless they have
> > common sense.  There were previous bugs with text editor(s) which used
> > logfiles to push the payload.  Why someone would ever decide to
> > include parsable logfiles directly into a script is beyond me, and I'm
> > sure is even beyond the kid that has been tinkering around the crap
> > known as php, a god awful scripting language, for but a single day.
>
> You're almost, but not quite right - the crucial point you slid right past is
> that it's "nobody knows about unless they have common sense *and* *a* *reason*
> *to* *be* *security* *conscious*".
>
> It's a subtle point that those *in* the security industry have a hard time
> remembering.  Things like SQL injections happen because the guy who wrote the
> code and forgot to sanitize the input string is in a certain mindset at the
> time.
>
> He is *not* thinking "I better be careful that some hacker from whatever
> they're calling Yugoslavia this decade doesn't get in".  He's thinking "the
> boss wants this new web reporting system working by next Friday".  So he never
> tests whether the page blows up if it sees apostrophe semicolon more SQL
> statements, because what's *supposed* to be in that field is a phone number,
> and phone numbers never have apostrophes.  And he's too busy worrying about
> things like "some people enter 555 1212 and some enter 555-1212 and some enter
> 212-555-1212 and some enter +1 (212) 555-1212 and there's one guy in the Hong
> Kong office that killed the *last* system when he put in some string that
> didn't have 7, 10, or 11 numeric digits, it was like 15, and all of it has to
> be converted to one format for the database...."
>
>

Yes, good point; This is a security mailing list though, so it was
somewhat implied but should not have only been infered.