jdamato

Thanks for commenting this! I've seen this website before and it's really unfortunate how much attention it gets.

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.

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 ;)

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!

[1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g... [2]: http://man7.org/linux/man-pages/man7/vdso.7.html

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.

Author here, greetings. Anyone who finds this interesting may also enjoy our writeup describing every Linux system call method in detail [1].

[1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

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.

Author of the post here: greetings.

If you enjoyed this post, you may also enjoy our deep dive explaining exactly how system calls work on Linux[1].

[1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

Check out the post linked from the article: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g... to learn more about how system calls work on x86 Linux.

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.

[1]: https://blog.packagecloud.io/eng/2016/06/22/monitoring-tunin...

Thanks for this!

I recently wrote a deep dive in to both strace [1] and Linux system calls [2] which may be interesting to folks reading this great article.

[1]: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...

[2]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

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.

[1]: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...

[2]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

I wrote an article explaining how ptrace works, which may interest you: https://blog.packagecloud.io/eng/2016/02/29/how-does-strace-...

Hi:

I built packagecloud, which is what GitLab uses for hosting packages.

Getting a package repository installed securely is quite a bit more difficult than it seems, but I agree that our Manual install instructions should be simplified and improved. I'll see what I can do about making them better.

As far as the hostname goes: we used it simply because its a unique identifier for the machine, but really anything could be used (like a MAC address or whatever). This is used because private repositories have tokens issued against a unique identifier, so a machine reinstalling a repo won't generate a new read token. I'll add a comment to the bash script explaining this, and consider adding an override in the future so that users can specify another identifier of their choice instead.

This is why a request to the server is required: it generates a read token server side which is then implanted into the APT repository configuration for the local machine so that the local machine can access the repo.