News for hackers. Stuff that matters.

A comment on Remote code execution vulnerability in apt/apt-get. Parent comment

Re:Remote code execution vulnerability in apt/apt-get by geofft on Tuesday January 22, 2019 @12:30PM (#18970177)
No, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use.

Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

[ Parent | on HN ]
Re:Remote code execution vulnerability in apt/apt-get by zaarn on Tuesday January 22, 2019 @12:34PM (#18970221)
Defense in depth is a thing.

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.

[ Parent | on HN ]
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 ]