I suspect we will eventually determine that using n libraries/frameworks/layers tends to produce O(n!) security holes because the pieces interact to form exploits that weren't in any specific one alone.https://github.com/oskarsve/ms-teams-rce/blob/main/README.md …
-
Show this thread
-
Replying to @cmuratori
Point of order: Layered frameworks/libraries, which is the overwhelmingly common case, are not stacked in arbitrary order. If A requires B, then B does not typically require A. So it would be O(2^n) not O(n!).
1 reply 0 retweets 0 likes -
Replying to @deguerre
I would say, with the exception of specific tier split points, often times A and B interact bidirectionally to produce holes. Like all JavaScript interacts bidirectionally, for sure.
1 reply 0 retweets 3 likes -
Replying to @cmuratori
True, in the case of weakly-typed callbacks and return values. In which case that would still be O(2^n) with a higher constant factor. My reasoning is that the chance of a security hole is proportional to the number of subsets of the set of all components.
2 replies 0 retweets 0 likes -
Replying to @deguerre
I don't see why it would be O(2^n). A composite exploit works in a particular "order" (like payload in here, timing there, return gadget at end). So however many n you have, you can try arranging their pieces in arbitrary orders to create new potential working exploits, right?
2 replies 0 retweets 1 like
Like, for example,https://en.wikipedia.org/wiki/Return-oriented_programming …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.