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.
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!
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 ;)
Not quite. The vDSO provides a general syscall-wrapper mechanism for certain types of system call interfaces. It also provides implementations of gettimeofday clock_gettime and 2 other system calls completely in userland and acts precisely as you've described.
Please see this[1] for a detailed explanation. For a shorter explanation, please see the vDSO man page[2]. Thanks for reading my blog post!
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.
> 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.
If you enjoy this post, you may also enjoy the companion post which dives into the same level of detail, but for the receive side[1].
I set out to write all this up because so much of the existing documentation (including the man pages) is vague, incomplete, or nonexistent. FWIW, I think this is probably to be expected for a system as complex as the Linux kernel.
Great introductory article, thanks for writing and sharing this!
I wrote an article explaining the inner workings of strace [1], and a detailed article about Linux system calls [2] which others interested in this article may find relevant.
APT's use of plain text HTTP (even with GPG) is vulnerable to several attacks outlined in this paper: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p....
Yes, this paper is old, but APT is still vulnerable to most of these attacks. I would advise anyone wanting to use APT to do so only with TLS.