Re:Remote code execution vulnerability in apt/apt-get
by moviuro on Tuesday January 22, 2019 @12:42PM
(#18970298)
Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over.
Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
Re:Remote code execution vulnerability in apt/apt-get
by blattimwind on Wednesday January 23, 2019 @08:42AM
(#18977983)
> Priv-sep
Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.
Re:Remote code execution vulnerability in apt/apt-get
by tracker1 on Tuesday January 22, 2019 @02:39PM
(#18971628)
And overcoming both is much harder than overcoming either on their own.
Re:Remote code execution vulnerability in apt/apt-get
by moviuro on Tuesday January 22, 2019 @02:46PM
(#18971699)
In the worst case, you only need to overcome one. And you ~double your attack surface.
Re:Remote code execution vulnerability in apt/apt-get
by tracker1 on Tuesday January 22, 2019 @06:14PM
(#18973718)
Which one? If you gain control of a server, you'd still have to overcome signing... and you only control that single server, not all replicas (for a bug like in TFA).
Could you describe a way to have double the attack surface that would effect the majority of peer servers?
SSL provides some security guarantees.
Using signed package databases also provide some security guarantees.
Both may overlap in what security they provide.
BUT!
If one fails, the other can continue to provide a subset of the previously available guarantees.