5 ms·
I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http
by jmvoodoo 8y ago
I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http and therefore wouldn't reduce the security of the overall system. It adds one more hurdle for an attacker to clear.
Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.
- moviuro 8y ago> adding https over http for the current system would always improve security No. If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln. Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545
- jmvoodoo 8y agoFair. There are specific library attacks that could result in RCE. However that is also true against curl, ssh, and for that matter could be introduced into your http library at some point. The question then becomes what library do you trust most? OpenSSL is attacked and tested constantly. Things have been found (in your example in 2003!). They have been fixed. Apt can choose to stand on it's shoulders, or go through the entire process themselves by putting together a patchwork of their own solutions that will no doubt get less testing by whitehats and be a juicy target for blackhats.
- giovannibajo1 8y agoEven ignoring the fact that there are far better libraries than OpenSSL today (eg: BoringSSL), apt already implements a sandbox-like approach (as the article explains); I'm not sure if the subprocesses are actually sandboxed, but obviously they should and at that point, a vulnerability like the one you cited shouldn't let the attacker escape the very narrow sandbox.