full-disclosure - Cisco Bug 44020

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]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Cisco Bug 44020 - Final Thoughts 

On Thu, 24 Jul 2003 10:56:00 EDT, bill.noren@...tec.com  said:

> prior to that in the same e-mail.  I'm not a programmer by any stretch of
> the imagination but I found it curious that the C library had no kind of
> error checking for valid values in the protocol field. 

1) The "C library" has no read way of telling which protocols are "valid"
for any given packet - if the packet is going over the network, it won't
know for sure that protocol 50 is or isn't valid at the destination until
it gets there.  What usually happens if it's invalid is you get back an ICMP
packet with type=3 (Dest Unreachable) with Code=2 (Protocol Unreachable).

2) C has type-casting and type-coercion rules that you can get bit by.   Yes,
you may have an "int" going from 0 to 1023, and you're assigning it to a 8-bit
quantity.  This will silently truncate and assign the low-order 8 bits.  This is
probably what bit you...

> It basically "did what it was told".

That's the basic design philosophy of C, actually.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030724/4e63a972/attachment.bin