full-disclosure - How T-Mobil's network was compromised

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]

From: frank at knobbe.us (Frank Knobbe)
Subject: How T-Mobil's network was compromised

On Sun, 2005-02-20 at 01:09 +0200, Willem Koenings wrote: 
> > I've seen cases where user input is correctly sanitized, but there was a
> > flaw.
> 
> Can you please bring an example?

I'll give you three:

1) User input is passed to a function which sanitizes the input by
converting "dangerous" characters to HTML representations. Function
works perfectly, changes < into &lt;, > into &gt;

Function is flawless from a programming perspective and performs as
written. The only flaw was on a logic perspective since the function
forgot to change " into &quote;

(That's an obvious example. What I have observed all too often is a
change of all known hostile characters. Yet chars >=255 and <32 are not
examined/converted).

2) User input is passed to a function which munges the input and
converts in the input strings to output strings. Works perfectly,
changes all characters except harmless ones.

Function is flawless from a logic perspective and performs as expected.
The only flaw is a missing call to free() which results in a memory
leak.

3) (and based on a recent example, I just can't find the reference... it
was some PHP app): Input URLs are examined for "../" and converted into
"./". The function worked correctly, no flaw from a programming
perspective. However, input of ".../" was converted to "../" as planned,
but leaving the application still vulnerable. 

(Note: I don't think the fix to that problem was all that great. What
should have occurred is a check for "../" in a loop. Change and replace
as often as "../" is found. There was no such loop in the suggested fix
afair)

The point is that often code works correctly, stable and secure, and
does what the programmer intended to do. However, sometimes the
programmer overlooked a condition to check for. The lack of that check
is not a flaw in the code. A reviewer may not find it because he may not
conceive a requirement for such a check either. So the code is correct,
no flaws in it. Yet it will fail under certain conditions.
We can only check for the existence of those flaws that we are aware of.
We can not say that tested code does not have flaws that we didn't
conceive.

Regards,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050220/b3b162cc/attachment.bin