© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I won't try to do what would be a half-baked assessment.
Looking at how the code behaves and the lack of structural guarantee around reuse of conjunction IDs, additionally to the possibility of having legitimate traffic be dropped (which I would say is established given what we saw on this deployment), the code is written in a way that seem to let open the possibility of having illegitimate traffic be accepted.
In the rough and incomplete analysis above, I mentions cases where I think this may happen:
> if R1a-3 is setup before R1a-1/2 are, until R1a-1/2 are setup, we would have SGFLow2 mapped to Y (old state prior to restart), and rules in place so that traffic matching "to_port(N)+ conj Y" send to port N.
In the general case, traffic matching SGFLow2 will not also match to_port(N) conditions, but this is messy to analyze further and be sure that no illegitimate traffic can go through.
> SGFlow1 remote SG matching has replaced SGFlow2 remote SG match in the computation of Y.
> New rules for conj(Y) select traffic for SGFlow1, and based on this R1a-3 forwards to N (ok) and R2b-3 forwards to K, which would be a firewall violation, although it seems that to leverage this to inject traffic the destination MAC would have to be tailored.
Again, my analysis is incomplete, digging further is needed and may lead to discover that there are more cases where firewall violations may happen, or lead to conclude that despite lack of structural guarantees, the code would avoid the problematic cases.
(e.g. I didn't dig the possible intermediate state where traffic would hit the flow rules in a state where R1a-1 has been setup but R1a-2 hasn't been setup yet - this combination would lead to traffic be accepted based on wrong source IP classification, and quite an obvious case of accepting illegitimate traffic -- but maybe the code does the rule insertion in an order that prevents this from happening)
There are additional conditions that for sure would need to be met for an attacker to exploit this:
* be sending traffic when the OVS agent restart occurs (always sending traffic can allow to meet this condition)
* hit a race condition (an attacker may "encourage" this by using lots os SGs, or SGs with large port ranges to increase the amount of OVS flow rule and increase the restart time)
So, while none of what I saw leads to conclude that this is easy to exploit, I would say that without a deeper analysis, it's not easy to conclude what are the cases where an attacker could manage to have illegitimate traffic be accepted.