netdev - Re: [PATCH][RFC] tcp: fix ambiguity in the `before' relation

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Jan 2007 11:51:16 +0000
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Herbert Xu <herbert.xu@...hat.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH][RFC] tcp: fix ambiguity in the `before' relation

|  > The key point where the new definition differs from the old is that _the relation_
|  > before(x,y) is unambiguous: the case "before(x,y) && before(y,x)" will no longer occur.
|  
|  This is highly dependent on how the before macro is used in actual code.
|  There is nothing to suggest that this change won't create new security
|  holes in DCCP or any other protocol that uses this macro.  The only
|  way to be sure is to audit every single use.
I fully agree, merely changing the definition means going only half way.

|  So I think we need to do one of two things:
|  
|  1) Audit every single before/after check to ensure that it works
|  correctly with the new definition.
For DCCP I will perform such an audit and post the results to dccp@...r. 

With regard to TCP: I am heavily snowed under with other work at the moment. If there
are experienced TCP people on the list who would be happy to look at this, it would be
great. I counted the number of times before() is used - it amounted to 68. There are
of course obvious cases which are quick to dismiss, but in particular the example you
presented yesterday points out that careful analysis is needed.

I asked Dave to revert to the old TCP definition (patch has been committed); for the moment
this seems the safest thing to do.

|  2) Change before/after such that before(x, x+2^31) == !before(x+2^31, x).
This is what the new definition does: in the old definition we always have that
before(x, x+2^31) == before(x+2^31, x).
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html