jdamato

APT will not reject it on replay if the 'Valid-Until' date has not been met yet.

Imagine a version of, say, libEXAMPLE has a vulnerability allowing remote code execution. The `Valid-Until` date is some time in the future, maybe a few days from now. The authors release a new version of libEXAMPLE to patch the vulnerability and the APT repository metadata is updated.

However, a malicious actor performing a MitM against your machine has saved the metadata with the vulnerable version. The malicious actor replays that metadata to your system, preventing your system from seeing the newly patched libEXAMPLE. This gives the attacker up until the `Valid-Until` date to attempt to launch an attack against you.

Yes, plain text APT repositories (signed with GPG or not) are vulnerable to freeze attacks.

We never suggest that you turn security off -- several versions of APT come with various settings defaulted to off, as described in the article.

All of the attacks presented (replay attacks, freeze attacks, and downgrade attacks) affect GPG signed APT repositories.

Hi!

I'm the author of the article. We never suggest turning off GPG and checksum verification.

The bugs may be in APT, but they allow several attack vectors against APT, as explained throughout. Let me know if you have any specific questions and I'd be happy to help clear things up!

The website you linked to has several factual errors, as explained in the article.

Yep, and the information is still relevant! The article explains how it applies to recent versions of APT in the current Ubuntu LTS releases.

We don't really know what EC2 does or precisely the type of hardware your VM will be spun up on. I've erred on the side of being cautious due to the vast amount of work being invested in timekeeping in various hypervisors. If EC2 knows that the TSC clocksource is safe on all of its hardware, perhaps modifying the Amazon Linux AMI to set TSC as the default clocksource would reassure many folks, myself included.

Advanced users that can run their own analysis or who have applications which would withstand potential time warps, are of course, free to ignore my warning at their own risk ;)

This is precisely what the vDSO does. The clocksources mentioned explicitly list themselves as not supporting this action, hence the fallback to a regular system call.

Thanks for reading and I'm glad to hear you loved my post!

Hi, both are answered in the article:

First:

> What’s going on here is that the first call to localtime in glibc opens and reads the contents of /etc/localtime. All subsequent calls to localtime internally call stat, but they do this to ensure that the timezone file has not changed.

and second: read the section titled "Preventing extraneous system calls" for the answer to your second question.