Comments on: Vulnerability Complexities http://ddos.arbornetworks.com/2006/04/vulnerability-complexities/ A weblog dedicated to educating the community on security threats that matter Sun, 29 Jan 2012 02:23:23 +0000 hourly 1 http://wordpress.org/?v= By: ivan http://ddos.arbornetworks.com/2006/04/vulnerability-complexities/comment-page-1/#comment-774 ivan Wed, 16 Aug 2006 16:37:02 +0000 http://asert.arbornetworks.com/2006/04/vulnerability-complexities/#comment-774 The relationship between CORE and SNI was quite simple: CORE did software development for SNI under contract. Basically we developed a bunch of vulnerability checks for Ballista. In the process we uncovered some bugs and developed some interesting things. The statd bounce was one of them, another one is the first (as far as I know) return-into-libc exploit that gera wrote for some old sendmail bug, a first attempt at a more rigorous verification of randomness for TCP ISNs, DNS attacks with predictable query IDs, NIS+ bugs, FTPD bouncing, other Sun RPC tricks using the portmapper and a few other things that I surely forgot about already. There was no official advisory from Core or SNI about statd bouncing but a public discussion about it appeared on bugtraq in 98-99. We did not deem the finding "groundbreaking" and worthy of an advisory, it just proved that local RPC services could be reached remotely. Later in 1999 CERT did release an advisory about it but back then they did not have the habit of crediting the security researchers that found bugs. http://www.landfield.com/isn/mail-archive/1998/Apr/0109.html The relationship between CORE and SNI was quite simple: CORE did software development for SNI under contract. Basically we developed a bunch of vulnerability checks for Ballista. In the process we uncovered some bugs and developed some interesting things. The statd bounce was one of them, another one is the first (as far as I know) return-into-libc exploit that gera wrote for some old sendmail bug, a first attempt at a more rigorous verification of randomness for TCP ISNs, DNS attacks with predictable query IDs, NIS+ bugs, FTPD bouncing, other Sun RPC tricks using the portmapper and a few other things that I surely forgot about already. There was no official advisory from Core or SNI about statd bouncing but a public discussion about it appeared on bugtraq in 98-99. We did not deem the finding “groundbreaking” and worthy of an advisory, it just proved that local RPC services could be reached remotely. Later in 1999 CERT did release an advisory about it but back then they did not have the habit of crediting the security researchers that found bugs.
http://www.landfield.com/isn/mail-archive/1998/Apr/0109.html

]]> By: tqbf http://ddos.arbornetworks.com/2006/04/vulnerability-complexities/comment-page-1/#comment-7 tqbf Sat, 15 Apr 2006 04:14:13 +0000 http://asert.arbornetworks.com/2006/04/vulnerability-complexities/#comment-7 IIRC, the bounce attack belonged to CORE SDI S.A., which had an interesting (read: I don't understand it) relationship to Secure Networks and to Network Associates, who owned us when this bug was current. My guess is, between that and the fact that the statd bounce isn't so much an "exploitable hole in someone's software" as a "crippling design defect in a protocol", we never really had the impetus to drive to a vendor patch, and thus to an advisory. By way of example, we didn't release ToolTalk until after the "in-the-wild" exposure got completely ridiculous; without the exploit sightings, vendor patch reluctance probably would have kept that advisory hidden. IIRC, the bounce attack belonged to CORE SDI S.A., which had an interesting (read: I don’t understand it) relationship to Secure Networks and to Network Associates, who owned us when this bug was current.

My guess is, between that and the fact that the statd bounce isn’t so much an “exploitable hole in someone’s software” as a “crippling design defect in a protocol”, we never really had the impetus to drive to a vendor patch, and thus to an advisory.

By way of example, we didn’t release ToolTalk until after the “in-the-wild” exposure got completely ridiculous; without the exploit sightings, vendor patch reluctance probably would have kept that advisory hidden.

]]>