Comment 5 for bug 1899193

Don't worry, it's in the right spot, I just thought it's an aptdaemon bug from the messaging, but then it's 3 (well 4) bugs spread all over apt, python-apt, and (policykit) aptdaemon.

Practically speaking, the main problem is the late policykit check, not the bugs in the C code, because once you passed that, you are in the trusted zone anyway. The package scripts run as root a few moments later anyway, and that gives me much better opportunities to do harm. Or you install setuid binaries.

In summary, the input to those daemons (and apt binaries) that run as root must be trusted. Now neither has (had for PK) appropriate checks at the right spot, so well, that's bad. I wonder what QApt does.

Now, aptdaemon isn't used much anymore past 16.04 - only for non-security updates, so the impact of DoS-ing aptdaemon is not the most critical out there, which is good. The rest installs via PackageKit or directly using apt (security updates). And I think aptdaemon does not acquire locks at the point where those issues happen, so security updates would still apply fine.

There is software where I think this is more critical, e.g. archive management like Launchpad and dak uses it to analyse packages, and you can then crash certain queues or hang them. Now Launchpad has some protection by running them separately, but I'm not sure how well it deals with those infinite loops - if one queue "hangs". So basically, you can DoS whatever archive(s) you can upload too.