full-disclosure - Re: phpBB 2.0.17 (and other BB systems as well).

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 Oct 26 06:18:37 2005
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Re: phpBB 2.0.17 (and other BB systems as well).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Morning Wood wrote:
> By prepending image headers you can often fool php/IE.
> This technique has been used successfully to bypass php checking
> and renders the php upon access.
> -----------------------------------------------
> ???? .JFIF
> <?php
> some phpcode
> ?>
> -----------------------------------------------
[snip]

In that case, that's a massive hole in the application that needs to be
plugged at the server side.  My thoughts on this are:

1) Requests for uploaded files should *not* be able to render
server-side code.  If this happens, the app has huge problems that need
to be fixed by a redesign/securing of that particular web application.

2) Responses indicating images should be treated as images.  Microsoft's
curious placement of this feature in the "Security" settings of its
browser leads me to think that they may have thought this would plug a
few of the instances where the badly bungled internal parsing of IE
opens security holes.  However, it seems to have had the opposite effect
in this case.

It is unclear to me if this is an SP2-only issue.  If it is, it can be
effectively mitigated by setting "Open files by content, not file
extension" to "Disable".  At the very least, Microsoft should turn off
this disastrous mistake of a "feature" in XP SP3.  Perhaps sooner...
like in the next IE critical update.

When I was asked about a year ago to help draft tech policy for a
certain public educational institution, I stalled the submission of the
policy until I received assurances that use of IE would be eliminated
there within two years of enactment of said policy.  Huge design errors
like this are the main reason why, with IE's horrendous time-to-patch on
discovered vulnerabilities a close second.

The engine for file rendering within IE needs a complete rewrite --
something SP2's LMZ lockdown attempts to mask.  Unfortunately for
Microsoft, its users would not tolerate an IE that returned them to the
digital stone age of simple HTML for every piece of content it ever touched.

It is unfortunate for me as well, because barring a huge overhaul and
rewrite of most of its parsing and access control code, IE as it stands
today has not got a prayer of ever being secure.  We can always hope for
a miracle in IE7, but I'm not holding my breath.

In the interim, I recommend the following workaround for IE's bugginess:

cd "%ProgramFiles%\Internet Explorer"
cacls iexplore.exe /D Everyone

Otherwise, just be prepared to deal with worms, trojans, and other
scumware as a fact of life.

Regards,
Matt Murphy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDXxGefp4vUrVETTgRA2QJAJ0RCnVr13zTQPojPLFjGliPByIEWwCfdngQ
EkvHyaRA4RQ06/4PCz1skMU=
=odd9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3436 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051026/75821908/smime.bin