Re: [Full-Disclosure] How T-Mobil's network was compromised

• Previous message: Jordan Klein: "Re: [Full-Disclosure] this is fun?"
• In reply to: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Next in thread: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Reply: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Reply: Allan: "RE: [Full-Disclosure] How T-Mobil's network was compromised"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: Willem Koenings <infsec@gmail.com>
Date: Sun, 20 Feb 2005 10:50:47 -0600

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• application/pgp-signature attachment: This is a digitally signed message part

• Previous message: Jordan Klein: "Re: [Full-Disclosure] this is fun?"
• In reply to: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Next in thread: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Reply: Willem Koenings: "Re: [Full-Disclosure] How T-Mobil's network was compromised"
• Reply: Allan: "RE: [Full-Disclosure] How T-Mobil's network was compromised"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]