Remote code execution vulnerability in apt/apt-get

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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?

[ Parent | on HN ]