[Full-Disclosure] How T-Mobil's network was compromised
frank at knobbe.us
Sun Feb 20 16:50:47 GMT 2005
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 <, > into >
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 "e;
(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
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
Full-Disclosure is hosted and sponsored by Secunia.