4 ms·

Why I specified "fixed URLs", to close that loophole

by willvarfar 6y ago

yjftsjthsd-h 6y ago
My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.
- kyboren 6y ago
  This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
  - pdkl95 6y ago
    > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html
- deleted 6y ago
  [deleted]
- yencabulator 6y ago
  So restrict it even further: extension manifest lists URLs, contents of which shall be made available to the extension, but keep the browser in control of when to fetch, with an enforced minimum cache lifetime.

Why I specified "fixed URLs", to close that loophole

yjftsjthsd-h 6y ago

My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.

kyboren 6y ago
This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
- pdkl95 6y ago
  > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html
deleted 6y ago
[deleted]
yencabulator 6y ago
So restrict it even further: extension manifest lists URLs, contents of which shall be made available to the extension, but keep the browser in control of when to fetch, with an enforced minimum cache lifetime.