Do you think there might be even more still lurking out there?
And what is your take on HTTPS for apt? I assume the MitM scenario for this and the previous bug could have been avoided by the use of HTTPS by default?
HTTPS would have mitigated this particular bug but it feels like rearranging deck chairs on the titanic to fight over that right now. We need to audit everything with powerful AI like, yesterday.
I'm sure Debian was invited to take part in Project Glasswing back at the beginning of this year.
I wonder if all the people who laughed off Anthropic's sensationalistic claims about Mythos as marketing fluff have recanted, or if they're too busy patching, or maybe they're stochastically parroting Ed Zitron's latest blather.
I do. I think that security-critical but overly complex software like this should be rewritten and certain aspects of it formally verified, since such things are now practical.
There have already been quite a few vulnerabilities in the implementation that would have been avoided if the transport itself was simply protected in line with the industry standard practice of using TLS by default.
The ones I looked at could be summed up to "well the redirects are misbehaving again"
Assuming transport is compromised and you can only trust package signatures IS A GOOD THING. Extra security layer on top of it is nice of course but arguably if it was all https we would've never found this bug and then in case of CA compromise attacker would have plenty of bugs to use to fool apt.
The problem is that they failed ordering of validation; it should be "download from source" (of any type, remember that http(s) isn't only way) -> put into temporary dir -> validate, regardless of source used.
There are also edge cases where HTTPS does hurt you, on system without reliable time (and there is quite a few SBCs that don't have RTC) you would just not be able to download the packages at all because all certs are in future.
Not exactly sure how would a system be able to connect to Internet to download package updates but be unable to source a correct time reference from NTP?
But yes, it should probably be a Debian installer question: use HTTPS sources or not. Debian is the universal operating system but most users running a desktop or server setup should choose YES. The setups where you really want plain HTTP sources are an edge case and users setting up such systems probably already know about their special requirements, so HTTPS sources should really be presented as the default / "if in doubt" option.
No word as of yet if Ubuntu's apt is also impacted.
Sounds like the vulnerability is in the HTTP handling code, and because apt downloads packages over plain HTTP a man-in-the-middle position would be enough to exploit it.
It almost seems like a repeat of two previous apt vulnerabilities:
Despite with the 'no need for TLS, apt packages are signed' clowns would have you believe, you can usually point to a package mirror with https. This has the added advantage of preventing a mitm from knowing what packages you install or blocking selected packages.
Apt uses persistent connections and has multiple requests in flight at once (Acquire::http::Pipeline-Depth). If you acquired the entire history of downloads then you could match it against software updates, and possibly identify by-choice dependency sets, but it would be quite a project.
> Updates for the affected Debian, Debian LTS, Debian eLTS, Ubuntu, and Ubuntu Pro channels are being released.
>
> An update for apt 1.0.1ubuntu2.24 has been made available to Ubuntu Pro customers running Ubuntu "trusty" through the Ubuntu Pro subscription service, and a 3.3.3ubuntu0.1 for stonking.
An attacker might replace a package with a previous one which has a vulnerability. Downgrade attack. Unclear if the apt client will check if version is the expected one after requesting a package.
Of course not, Debian is one of the most robust pieces of software around. They wouldn't do something idiotic like relying on the hash being sent with the payload through the same channel.
I think the idea is that debian distributes the hash themselves through their domain, and mirrors offer the downloads either through http or https. So that you don't need to trust the mirror, you just verify the debian given hash. Only weakness would be a hash collision or a cve like this.
AFAIK this isn't actually true for any distribution. This would break selfhosted mirrors and their clients hosted on airgapped networks, and create a single point of failure for users.
The way packages are validated actually is through the same channel as you download the packages themselves from (IE your mirror), they just are signed with the Debian package signing key(ring), of which only a select few maintainers have authorized private keys for.
This does mean an adversary (whether a MITM if you're using HTTP or malicious operator on the mirror server itself) can technically serve you old versions of an (officially signed) package indefinitely and your package manager would be none the wiser, but otherwise this approach actually works quite well.
No, DNSSEC tries to solve one part of the security of DNS (security of records between resolvers) and does nothing for the security between the user and their DNS server. And doesn't even do a good job at the bit it tries to solve.
It should, though it achieves that goal by a chain of certificates not unlike CAs just tied to DNS. Like I said, it essentially just moves the problem.
Which might still be better, if only because it limits the surface area.
DNSSEC deployment has been anything but trivial. This APNIC post from 2024 estimated that about 1% of DNS queries were being validated via DNSSEC: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/. That's more than 25 years after the IETF first standardized DNSSEC.
Is it really so that Time Division Multiplex timing in cellular networks is based on NTP time? I stopped reading after the article implied this - it doesn't sound plausible at all.
No. The official report seems to suggest that software in IMS core (the subsystem that controls VOIP signalling in the mobile network) bugged out after the time was shifted back 20 years. That doesn't narrow down the specific failure that stopped calls from going through very much. IMS core is full of timers, but it could also have been a license server issue for all the report said about it.
I haven’t read the report, but I did read at the time that it was a certificate validation failure: clients thought the current time was before the "Not Valid Before" date. I forget now what essential service became unavailable because it was disbelieved.
(Source would either have been the Whirlpool forums – where Australian ISP and telco engineers can be found – or local Australian mass media.)
This the most common failure mode I have seen with clocks being widely out of sync. You can't access many online services as the certificates are either dated to future or expired.
I would assume it’s similar to dab etc, and it’s ptp that carried that data on IP. In the broadcast tv world we use ptp, or more traditionally black and burst, or word clocks in audio.
The source is still the same - your grandmaster (ptp) or sync generator (b+b) is fed from a good timing source - often GPS, with one or two inputs, but sometimes local atomic clocks.
I’ve seen issues before with 40ms audio gaps when a GPS antenna has died and the coders can’t cope with frame drift so they incentive a 40ms silence in the audio every 40 minutes or so as the source and destination clocks are different speeds by about 1 part in 60,000.
In DAB the tolerances are far lower, there was a problem about 10 years ago due to a GPs satellite being a few microseconds off
Thank you, that definitely was an interesting read. Sad to learn of Bill Paxton's passing. Clearly his legacy and impact however live on, like this research demonstrates.
It seems he preferred the term "software instrument" to refer to MESA:
> Bildsten and Paxton have taken to calling programs like MESA "software instruments,” according to the latter. “Just like you can’t do observational astrophysics without an instrument like a telescope," he said, "you can’t do computational astrophysics without an instrument such as MESA."
It's amazing what impact one good piece of software, freely available to anyone anywhere to use, can have on a field. I think this quote illustrated the problem he was able to solve very well:
> Ideally, you want to be able to run an experiment, but you can’t go grab a star, run an experiment for a billion years, and come back later to see how it turned out.
One weird thing: the author of this clock/calendar portrays the year rotating clockwise (click on the calendar icon in top left to see the "annual" calendar): January in 12 to 1 o'clock, February in 1 to 2 o'clock, etc. and December in 11 to 12 o'clock.
In a poll of some close friends recently, we found out that most of us (>80% including myself) had always mentalized the year rotating counter-clockwise (starting from January at 12 to 11 o'clock, Februay at 10 to 11 o'clock etc. and finally December in 1 to 12 o'clock.)
Bizarely none of us could explain why we had such weird anti-clockwise mental image of the annual cycle, but all who viusalized the year running counter-clockwise said they had done so for as long as they could remember.
I actually have exactly a clock as a mental model of the year and the seasons. December is 12 o' clock.
But weirdly, I dont have a mind's clock to represent the day. Precisely because it feels to me that the clock shape is unfit to show time. Because 03:00am feels wildly different from 03:00pm. My mental representation is a 3d spiral slightly offset and looping back on itself. So imagine two clockfaces when looking from up top, seethrough. The bottom one is a bit to the left so you can see both well. Each consecutive number goes a bit higher. After 12 midnight the numbers quickly decend down back to 06:00am. I have this image for as long as.I remember.
I wonder if that's a common thing generally or not. Definitely I should add it as an option though. Also whether the year starts at the top or bottom of the dial.
The planets do go around the Sun anticlockwise when viewed looking down from above the North pole [0], and most diagrams show it that way, so maybe that's where the idea comes from?
Yes, this has to be where the picture originates. Given that almost all maps show the north facing up, picturing the Earth rotating anti-clockwise around the Sun throughout the year makes sense. A bit similar to how clocks for the times of day run clockwise probably because this aligns with the rotation of a sundial placed in the Northern hemisphere. In the Southern hemisphere, a sundial runs anti-clockwise.
Although, converse arguments can be made for both - even if we assume an observer located in the north. If we do indeed picture the Earth rotating in space from the outside - it actually rotates counterclockwise around its axis with the north up. So should day clocks actually run "backwards"? And the "fixed" background of distant stars seem to rotate around a northern observer in the clockwise direction throughout the year - so the image of the year rotating clockwise is just as correct.
Everything seems relative to the prespective chosen.
Interesting, I don’t have a circular mental image of the year at all. It’s more like a continuous line — the summers are light and the winters are dark(er) — where the previous year doesn’t coincide with the next year. Same for the week (and the month, but the months have different lengths anyway). Also not for the day, which takes two revolutions of the clock. Does anyone visualize the day as two circles? Probably not.
Agree. This is the first time I had thought about it this way and the clock representation seems fine.
Oddly the year is the only thing where I think I have a good 3D mental model without really thinking about it. Not sure if this makes sense to others but right now we are about 11/12ths of the way to the autumnal equinox and you can imagine the Earth’s tilted axis almost perpendicular to the arriving sunlight. I think of this as if I were observing from the sun so the axis is pointing up (north) to the left.
I picture day cycle in a single 24 hr counterclockwise loop. I’m always interested to learn about other people’s internal mental image frameworks! So fascinating.
I picture annual calendar the almost the same way (counterclockwise), although its an asymmetrical oval, and months have associated colors (i.e. December navy blue, January maroon/brown, February ice blue, March true maroon…August golden or wheat yellow). I don’t know why, but that’s been my mental image since childhood.
I visualize the year clockwise, but with summer at the top, and the new year at the 6 o'clock position. I'm not sure why, but I think it just makes more sense to me to think of spring as rising, and "fall" as descending. I guess that convention would work better in the southern hemisphere.
Right. If viewed with the north pole up, Earth indeed rotates counterclockwise around the Sun. Not sure if it would be any different for someone living on the southern hemisphere though, as all the maps used globally have the North up and the South down.
What stops you from going to work one hour early, so you get off earlier as well? Most employers these days allow flexible working hours.
And if we are permanently moving our clocks to advance by an hour, why stop at just one hour? Why not have +2h or +3h so we get even more brighter evenings.
"Most employers" definitely don't allow flexible working hours. You have to be in specific sectors – basically just "modern" tech companies – to have that privilege. And that is a very tiny slice of the working population.
Because most people don’t have that degree of flexibility. When I was commuting I’d have been happy to have double DST or whatever you want to call it.
reply