Professional Web Applications Themes

Clock slew vulnerability in FreeBSD? - FreeBSD

How vulnerable is FreeBSD to the recently announced technique for individually identifying computers by the clock slew apparent in TCP packets? If it is vulnerable to this, will there be any plans to address the vulnerability? -- Anthony...

  1. #1

    Default Clock slew vulnerability in FreeBSD?

    How vulnerable is FreeBSD to the recently announced technique for
    individually identifying computers by the clock slew apparent in TCP
    packets? If it is vulnerable to this, will there be any plans to
    address the vulnerability?

    --
    Anthony


    Anthony Guest

  2. #2

    Default Re: Clock slew vulnerability in FreeBSD?

    Is this technically a vulnerability, or is it just a side-effect of how
    computers operate? I was of the impression that this is quite an
    unavoidable issue, given how it seems to apply to any computer
    regardless of OS, but I haven't researched the issue much myself.
    Interesting question.

    Anthony Atkielski wrote: 

    Bnonn Guest

  3. #3

    Default Re: Clock slew vulnerability in FreeBSD?

    On Fri, Mar 11, 2005 at 03:45:39AM +0100, Anthony Atkielski wrote: 

    Isn't this a non-problem if you use ntpd?

    Kris
    Kris Guest

  4. #4

    Default Re: Clock slew vulnerability in FreeBSD?

    Bnonn writes:
     

    It's a vulnerability in the sense that it can leak confidential
    information about a system's identity. It's not a side-effect of how
    computers operate, but rather a side-effect of how most TCP stacks are
    implemented.
     

    It seems to be unavoidable only in the sense that most operating systems
    are not designed to protect against it (yet). I think the claims of the
    researchers are overly optimistic, but time will tell.

    In any case, in the interest of security, it would be nice to see it
    addressed. I read that FreeBSD can be configured to avoid the problem
    completely by disabling the timestamps upon which the technique depends,
    but I don't remember the details. And if one still wants to use
    timestamps, it would be good if they could be used without leaking any
    information.

    --
    Anthony


    Anthony Guest

  5. #5

    Default Re: Clock slew vulnerability in FreeBSD?

    Kris Kennaway writes:
     

    Unfortunately, no, because the TCP stacks on most systems don't use the
    disciplined clock provided by NTP for the timestamps. Instead they use
    a clock based directly on the RTC, which reveals a characteristic skew
    that is unique to each machine.

    If the stacks used the NTP-disciplined actual time of day, plus perhaps
    a randomizing factor to avoid revealing patterns, this technique would
    become useless.

    --
    Anthony


    Anthony Guest

  6. #6

    Default RE: Clock slew vulnerability in FreeBSD?


    Your talking about this:

    http://www.caida.org/outreach/papers/2005/fingerprinting/
     

    "The basic idea is that you use TCP timestamps to estimate how fast or
    slow the remote clock is running. This doesn't give you enough
    information to uniquely identify the remote machine, but it does give you
    a way to assess whether two given machines are the same. Possible uses
    include determining when two machines that have the same address are in
    fact different machines (e.g., they're behind a NAT) or whether two
    machines with different IP address are actually the same machine (e.g., a
    honeypot)."

    Anthony, I think your a bit mistaken in your description. This does not
    appear to be
    much of a security hole. NAT's are defacto these days on the Internet
    and any cracker
    is going to assume that there's a good chance he's attacking a NAT.

    Ted
     

    Ted Guest

  7. #7

    Default Re: Clock slew vulnerability in FreeBSD?


    On Mar 10, 2005, at 10:44 PM, Anthony Atkielski wrote:
     
    >
    > Unfortunately, no, because the TCP stacks on most systems don't use the
    > disciplined clock provided by NTP for the timestamps. Instead they use
    > a clock based directly on the RTC, which reveals a characteristic skew
    > that is unique to each machine.
    >
    > If the stacks used the NTP-disciplined actual time of day, plus perhaps
    > a randomizing factor to avoid revealing patterns, this technique would
    > become useless.[/ref]

    Wouldn't the skew resolution necessary for this tracking technique
    become useless with temperature variations, humidity, etc. that can
    affect most systems over the course of the day/week/year?

    Bart Guest

  8. #8

    Default Re: Clock slew vulnerability in FreeBSD?

    Bart Silverstrim writes:
     

    That's one of my questions, too. A technique that could identify 100
    million different computers (as some people have speculated) would need
    reliable precision to at least nine decimal places. That's a pretty
    tall order for something like measurement of clock slewing in TCP
    packets.

    There are other related problems. So you identify computer A using its
    unique clock slew. How do you prove that in court? If you move the
    machine, or if you change anything about it, the RTC is likely to vary a
    bit, changing the slew to a different value. Just temperature
    variations in the room can do that.

    --
    Anthony


    Anthony Guest

Similar Threads

  1. Compile FreeBSD RELENG_5 on FreeBSD 4-STABLE
    By Brovo Karokin in forum FreeBSD
    Replies: 1
    Last Post: February 25th, 09:04 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139