OpenBSD Journal

OpenBSD Hackathon 2005, Part III

Contributed by grey on from the cisco, ietf, cert, politics and triumph dept.

Thanks to teemu and Chris for pointing out another addition to Kerneltrap's coverage of c2k5. This time focusing on Fernando Gont, whom I had the pleasure of meeting after he presented on ICMP related attacks at core05. The article discusses the attacks, as well as OpenBSD's encorporation of fixes and the headaches of dealing with politics within the industry with regards to Cisco, IETF, CERT, NISCC, patent claims and more.

The complete article may be found here: http://kerneltrap.org/node/5382

(Comments are closed)


Comments
  1. By Han (82.73.147.65) han@mijncomputer.nl on

    Great article. Fascinating to see how people can still put dot's on the i's when it comes to coding. Kerneltrap has a real interest in the technology of development. No wonder it's the most linked website.

  2. By Anonymous Coward (68.202.43.80) on

    Very interesting to see the behind-the-scenes dynamics of reporting security issues. Reading this article really drives home the importance of full disclosure, both to make the knowledge public and beyond the control of powerful interests, and as a threat/motivator held in reserve to make everyone behave as they should.

    If these companies really cared about their customers, they would be more concerned about quickly fixing such critical infrastructure problems rather than trying to patent the solution and extract money from everyone who is simply trying to protect themselves. This kind of problem affects us all.

    Comments
    1. By Han (82.73.147.65) han@mijncomputer.nl on

      The most cynical thing is that they sell you a whatever, with a security problem, and then also sell you a fix for the securityproblem they actually created themselves.
      I mean, that would be unheard of in any other industry.

  3. By Anonymous Coward (202.79.221.151) on

    this is really a good article, an eye opener and a real example of how big companies like cisco get their revenue from. thumbs up to openBSD for being responsive & helpful !

  4. By Oliver E. (62.65.148.234) on

    These ICMP flaws of TCP/IP and protection against them has been
    discussed numerous times in the past (and e.g let most vendors
    not implement source quench). It's not exactly rocket science to
    figure out vulnerabilities of connectivity resulting from ICMP
    either.

    While I fail to understand why this should be "news" of any kind,
    an Internet Draft to fix the protocol definitions is most welcome.

    Comments
    1. By teemu (193.110.28.9) on http://teemu.lynix.net

      you´re right, these aren´t news but beside that, it is still a good article.

      Comments
      1. By Anonymous Coward (62.65.148.234) on

        I was referring to the sentence "[..]he wrote about some flaws in
        the ICMP protocol, flaws he discovered while writing the "Security
        Considerations" of a different internet-draft[..]. The article
        then goes on with a quote from Theo: "Here we have a 20 year old
        protocol, a part of the Internet infrastructure that hasn't been
        touched in 10 years and we were all sure was right, and now is
        cast in doubt."
        
        The way *I* read the article, it clearly tried to point out that
        these flaws were just recently discovered. However, similar issues 
        have been pointed out e.g. in Bellovin's paper on "Security Problems 
        in the TCP/IP Protocol Suite" as early as in 1989 (note that the 
        paper predates PMTUD and consequently does not discuss security 
        issues related to it). 
        
        Again, some vendors have chosen to ignore ICMP Source Quench instead
        of passing it up to the transport layer protocol as mandated by
        RFC1122. Others have chosen to check TCP sequence numbers. Some 
        may do both, do different things or they don't do anything at all....
        
        So again:
           
              While I fail to understand why this should be "news" of any
              kind, an Internet Draft to fix the protocol definitions is most
              welcome.
        
        --Ol.
        
        

    2. By Anonymous Coward (143.166.255.17) on

      regardless of news or not no one was doing a damned thing about until Fernando got with it.

    3. By Jason Crawford (65.174.217.58) jasonrcrawford@gmail.com on

      I think this is more news because of the fact that these problems are so damn old. They havn't been fixed, or even "officially" acknowledged until now, and that's the real news. Commercial vendors keeping serious bugs under wraps to save some money, THAT's news. It's just sad that it hasn't been fixed until now.

  5. By Peter (62.141.24.1) on

    I'm sorry for OT. But maybe you have already see a new patch for zlib.

    Check http://secunia.com/advisories/15978/ it means system compromise from remote? Am I right?

    Comments
    1. By Anonymous Coward (193.63.217.208) on

      From what I read, this can execute code with the privileges of the target process. So in the default install, sshd using compression would be the only target and then only the unprivileged child in the privsep scheme would be compromised. Unless I am mistaken, preventing this sort of problem becoming a remote hole is the motivation behind privsep in the first place.

      Maybe someone who understands better could comment on if privsep or even pro-police would affect this?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]