Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On 12/19/2016 06:26 PM, Patrick Schleizer wrote: What about Debian graphical installer security? Isn't that in meanwhile the ideal target for exploitation for targeted attacks? Because it will take a while until the Debian point release with fixed apt. And during the gui installer, the output of apt-get is not visible. And stuff during installer taking a long time is something users have been trained to expect. So I don't think it would raise much suspicion. If exploitation works, fine, if not, nothing was lost. Also Debian gui installer may be distinguishable over the network from already installed systems? Because first it's using debootstrap (perhaps with special options), then apt-get. The timing or something else could make it distinguishable over the network. Best regards, Patrick Probably so. But an attacker can be opportunistic--try and maybe fail/succeed--whether or not the user is installing or merely updating. The only solid solution to this issue is to alert users out-of-band, and have them also obtain *new media out-of-band* so they can re-install. In our case on Qubes, dom0 updates can fill the need for obtaining new media. But going forward, the best practice would include issuing new ISOs as well, since users installing Debian alongside Qubes will perform normal updates as a matter of course--they may review new CVEs or QSBs but not from several months prior. BTW, I think Debian's idea expecting users to validate detailed metadata with their eyeballs is crazy. Chris
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
What about Debian graphical installer security? Isn't that in meanwhile the ideal target for exploitation for targeted attacks? Because it will take a while until the Debian point release with fixed apt. And during the gui installer, the output of apt-get is not visible. And stuff during installer taking a long time is something users have been trained to expect. So I don't think it would raise much suspicion. If exploitation works, fine, if not, nothing was lost. Also Debian gui installer may be distinguishable over the network from already installed systems? Because first it's using debootstrap (perhaps with special options), then apt-get. The timing or something else could make it distinguishable over the network. Best regards, Patrick
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Sat, 17 Dec 2016, Hans-Christoph Steiner wrote: > One thing that would help a lot with future issues like this is to use > only encrypted connections in /etc/apt/sources.list. That can be either > HTTPS or a Tor Hidden Service .onion address. For in depth discussion > of this, see: You could bootstrap from one of the larger ISO media which have the entire standard system and you can sha256sum easily, and install without any networks connected. Then, manually install the updated .deb packages using an USB pendrive or something like that. You can also sha256sum these easily. Then enable the network, and update the whole system as usual, and run "tasksel" as root to ask for more package sets, etc. It is worth notice all this crazy dance is going to become unnecessary as soon as the next debian stable point release is issued [with an updated installer image], and new install media are made available. I will ask the stable release team to consider speeding up the next Debian stable point-release timeframe based on this. > https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ Yeah, right. However Debian 8 (jessie) and earlier, i.e. the current Debian stable, runs the apt transports as *root*, and *unjailed*. For that reason, you do *not* want a complex set of libraries with an history of being zero-day nurseries anywhere near APT in Debian 8 (jessie) and earlier. If you enable apt-transport-https in Debian 8 and earlier, you increase the chances of [eventually] being remote-exploited a great deal. So, please go with the bootstrap from an ISO media instead. NOTE: apt in Debian Stretch (Debian 9), runs the transports as an unpriviledged user, which is a lot safer. You should still avoid using apt-transport-https there unless required, it is much safer to have a local mirror [properly set up]. -- Henrique Holschuh
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Patrick Schleizer: > Julian Andres Klode: >> (2) look at the InRelease file and see if it contains crap >> after you updated (if it looks OK, it's secure - you need >> fairly long lines to be able to break this) > > Thank you for that hint, Julian! > > Can you please elaborate on this? (I am asking for Qubes and Whonix > (derivatives of Debian) build security purposes. [1]) > > Could you please provide information on how long safe / unsafe lines are > or how to detect them? > > Ideally could you please provide some sanity check command that could be > used to detect malicious InRelease files such as 'find /var/lib/apt > -name '*InRelease*' -size +2M' or so? > > The problem is, > > - debootstrap can only bootstrap from one source such as > 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. > (Correct me if I am wrong, I would hope to be wrong on that one.) > > - bootstrapping from 'http://security.debian.org' is not possible > [contains only security updates, not a complete repository]. > > - So in conclusion one has a chance to get compromised when > bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get > upgrading from 'http://security.debian.org'. > > Is there any way to break this cycle? > > Best regards, > Patrick > > [1] https://github.com/QubesOS/qubes-issues/issues/2520 > One thing that would help a lot with future issues like this is to use only encrypted connections in /etc/apt/sources.list. That can be either HTTPS or a Tor Hidden Service .onion address. For in depth discussion of this, see: * https://labs.riseup.net/code/issues/8143 * https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/ * https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ For the official Debian Tor Hidden Service addresses including apt mirrors, see: https://onion.debian.org/ .hc
Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Sat, 2016-12-17 at 04:42 +0100, Marek Marczykowski-Górecki wrote: > On Sat, Dec 17, 2016 at 02:47:28AM +0100, David Kalnischkies wrote: > > In terms of stable (which seems to be what you are asking about) there > > is a trivial 99,9% shortcut: stable has no InRelease file for technical > > reasons ATM, so something is fishy if you get one (aka apt should > > display Ign lines).² > > Not fully true: > http://security.debian.org/dists/jessie/updates/InRelease It _is_ correct. security.d.o/updates is not the stable distribution. The reasons that David mentioned specifically apply to the stable distribution in the main archive - i.e. stable - and the way that it's signed, not any other repositories or distributions that sit alongside stable and may have stable somewhere in their names. Regards, Adam
Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Dec 17, 2016 at 02:47:28AM +0100, David Kalnischkies wrote: > The provided exploit used a 1.3 GB big InRelease file for that, which > works with some confidence on a sufficiently memory-starved i386 system > if you can live with the fact that this works only 1/4 of the time as > the rest of the time it will fail (or not) at the wrong moment resulting > in errors from apt. More recent (>= 1.1) apt versions bail if > a (In)Release file is larger than 10 MB which is further complicating > things. A good attacker therefore likely needs a way to put the machine > in a memory-starved state on demand – like DoS the webserver running on > the same box at the right moment. Timing and luck is really important. So, with apt >= 1.1 it is very unlikely (at least) to affect client, 64-bit system, right? In practice even older apt (stable) on 64-bit is hard to exploit, but not unthinkable (will probably require larger file and careful targeting for particular memory size; and a lot of luck), right? (...) > In terms of stable (which seems to be what you are asking about) there > is a trivial 99,9% shortcut: stable has no InRelease file for technical > reasons ATM, so something is fishy if you get one (aka apt should > display Ign lines).² Not fully true: http://security.debian.org/dists/jessie/updates/InRelease Anyway `wc -L` pointed earlier should do the trick. > ¹ Its complicated as many different code parts are interacting here, so > simply storing the split-result wasn't as easy as it sounds. The acquire > system rewrite we performed the last few years should make that possible > now. I wanted to look into that anyhow, just have to find the time as it > is still not as easy as it sounds. Just likely "possible". Good to know. Thanks for detailed answer. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYVLQmAAoJENuP0xzK19csEWYH+QGQ/ckrtFBYqnEg0yH3JRxI v5gFkiIEYKGVN94k+dRY+PRIJe+8AmD8p9AGyWGcA7+0lt8vR0l8djfGIkBTsZCa udcrVWRmlPf1jI0JypH+xm+1dUNOucy/E7+gcqkXy/AiBqfRcaR9vsRGvYgOfd+a i42CqHcQ3+QhGRO8mNEaIBXJr4leADZ5lRoddsFD/D4GQ5tR/xPnrVsZZhMbbPRW aUYaYZW2dqabNq1i5UJVWHXYNE/IcgMolvzC9mFSxGDDt7wALBhe8eqbADQdmTr2 9OaD8ptREZPB/ufg8jp1PN7qzw+lNUnL+3E1ZwzqwKfm4hCbfWZ+QEN6Sa4oWOI= =xVA9 -END PGP SIGNATURE-
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
First things first:
If you really want to pull packages by hand you need to pull libapt-pkg
as the faulty code is in the apt library (aka it effects aptitude,
synaptics, …). Updating apt only isn't changing anything…
Second: The DSA unfortunately didn't mention apt-ftparchive – if you
don't trust the source of the .dsc files it reads that might be the
better place to exploit this CVE…
so lets get into details:
On Fri, Dec 16, 2016 at 10:32:00PM +, Patrick Schleizer wrote:
> Julian Andres Klode:
> > (2) look at the InRelease file and see if it contains crap
> > after you updated (if it looks OK, it's secure - you need
> > fairly long lines to be able to break this)
>
> Thank you for that hint, Julian!
>
> Can you please elaborate on this? (I am asking for Qubes and Whonix
> (derivatives of Debian) build security purposes. [1])
>
> Could you please provide information on how long safe / unsafe lines are
> or how to detect them?
The exploit uses the fact that apt performs the splitting of a clear-
signed file multiple times, one time for verification and later again to
actual work with the "verified" data.¹ So you need to trick apt with the
same file to "see" sometimes the good and sometimes the bad stuff. How
do you do that?
The splitting code uses the function getline(3) and basically does the
same as the example code provided in the manpage – lets copy for
convenience:
| while ((read = getline(&line, &len, stream)) != -1) {
|printf("Retrieved line of length %zu :\n", read);
|printf("%s", line);
|}
This loop runs as long as there are lines in the file (stream) until no
line is left and getline returns -1 – expect that this isn't the only
case it can return -1. The manpage mentions bad arguments – we know what
we are doing, so that isn't the case aka we are fine. Are we?
No, getline can also fail if it can't allocate enough memory to hold the
complete current line (aka: The example code has the same 'exploit',
just that the action it performs isn't security relevant). So, all you
have to do as an attacker is put the target machine under enormous
memory pressure at the right moment so that the allocation fails and the
code incorrectly assumes end-of-file, so that your bad content at the
beginning of the file is treated as data instead of ignored as "garbage"
if apt had seen the later lines (with the signed data it had seen just
moments earlier while verifying).
The provided exploit used a 1.3 GB big InRelease file for that, which
works with some confidence on a sufficiently memory-starved i386 system
if you can live with the fact that this works only 1/4 of the time as
the rest of the time it will fail (or not) at the wrong moment resulting
in errors from apt. More recent (>= 1.1) apt versions bail if
a (In)Release file is larger than 10 MB which is further complicating
things. A good attacker therefore likely needs a way to put the machine
in a memory-starved state on demand – like DoS the webserver running on
the same box at the right moment. Timing and luck is really important.
> [some comments I had read elsewhere and just want to comment on here]
I am not trying to downplay the problem as such: I made a bubu (as it
was me who wrote that faulty code), it is a serious exploit and you
should upgrade BUT we had far worse things in the past, so don't get too
excited: The world hasn't ended yet.
In all honesty that CVE makes me a bit happy and proud as it means that
someone cared enough about some code I wrote to look at it searching for
a way to exploit it and THIS is the best they came up with. You never
get a note of "I looked, but couldn't find anything" and the default is
"nobody looked or cared" so in some twisted and strange way it is nice…
It is nicer than what can be deduced from many reactions from self-
called experts at least as some comments proof that they haven't
understood the CVE nor looked at all at the fix, which is a bit strange
as it means people seem to care, but don't look anyhow… dangerous
combination and not very encouraging.
> Ideally could you please provide some sanity check command that could be
> used to detect malicious InRelease files such as 'find /var/lib/apt
> -name '*InRelease*' -size +2M' or so?
That is likely all it takes.
You should also be able to look at the first line of the file and see
"-BEGIN PGP SIGNED MESSAGE-" there (without quotes). If that
isn't the case it must not be a problem, but it is with 99% confidence.
(I am working on some changes to make apt warn if that isn't the case,
but I kinda expect some strange repository somewhere to violate this.
Note that gpg does the same ignoring apt does here – but its usecase is
different with clearsigned mails and such where unsigned parts are
normal)
In terms of stable (which seems to be what you are asking about) there
is a trivial 99,9% shortcut: stable has no InRelease file for technical
reasons ATM, so something is fishy if you get one (aka apt should
display Ign li
Re: [qubes-devel] Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Dec 17, 2016 at 12:20:04AM +0100, Julian Andres Klode wrote: > On Fri, Dec 16, 2016 at 10:32:00PM +, Patrick Schleizer wrote: > > Could you please provide information on how long safe / unsafe lines are > > or how to detect them? > > > > Ideally could you please provide some sanity check command that could be > > used to detect malicious InRelease files such as 'find /var/lib/apt > > -name '*InRelease*' -size +2M' or so? > > Checking that wc -L (longest line) of the release file is reasonably small > (like 256, 512, or 1024) should be enough. Currently, it's about 140 chars > for unstable. wc -L seems like a good one-liner, thanks! > > The problem is, > > > > - debootstrap can only bootstrap from one source such as > > 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. > > (Correct me if I am wrong, I would hope to be wrong on that one.) > > Right now yes. That will contain a new APT in a point release. That said, > there might be issues in debootstrap's Release file verification, someone > should check that... It looks like it uses Release.gpg, so this bug do not apply, right? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYVHioAAoJENuP0xzK19csiL8IAIetZlBLlR8EiNvDouC1SRjw c028w+CB5+YOA8RUukwtgaoljpaHnPGZ67BFKTgw2UKq5Srk+LVebPOOKXBrYRAA h7Ku+nzhVIYagHAbqYQ1ZqsmWyI7JK1y0PjyDtdnp2RGQONWr1llP/gju9dVg5sg ABv2CUeH0+/RRNuTFXxP2MBeciwaWfHxfEVgSvxhRLlZUqiNblcZqi4YAWNET/WU kfe5ntASdCbcs+kjk0GTB0I8EmDp/lj4uH2Y+hI6eVuOYmoFTxNkkth2pf7gQfv9 0lePfhnaEpKbuyMAP6SIkYk0kq92iL796y2Hk2JPE4CgjBJ7LzCXD3qBG8LmZQ8= =jN+8 -END PGP SIGNATURE-
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Fri, Dec 16, 2016 at 10:32:00PM +, Patrick Schleizer wrote:
> Julian Andres Klode:
> > (2) look at the InRelease file and see if it contains crap
> > after you updated (if it looks OK, it's secure - you need
> > fairly long lines to be able to break this)
>
> Thank you for that hint, Julian!
>
> Can you please elaborate on this? (I am asking for Qubes and Whonix
> (derivatives of Debian) build security purposes. [1])
I added some details in that referenced bug :)
>
> Could you please provide information on how long safe / unsafe lines are
> or how to detect them?
>
> Ideally could you please provide some sanity check command that could be
> used to detect malicious InRelease files such as 'find /var/lib/apt
> -name '*InRelease*' -size +2M' or so?
Checking that wc -L (longest line) of the release file is reasonably small
(like 256, 512, or 1024) should be enough. Currently, it's about 140 chars
for unstable.
>
> The problem is,
>
> - debootstrap can only bootstrap from one source such as
> 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt.
> (Correct me if I am wrong, I would hope to be wrong on that one.)
Right now yes. That will contain a new APT in a point release. That said,
there might be issues in debootstrap's Release file verification, someone
should check that...
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Julian Andres Klode: > (2) look at the InRelease file and see if it contains crap > after you updated (if it looks OK, it's secure - you need > fairly long lines to be able to break this) Thank you for that hint, Julian! Can you please elaborate on this? (I am asking for Qubes and Whonix (derivatives of Debian) build security purposes. [1]) Could you please provide information on how long safe / unsafe lines are or how to detect them? Ideally could you please provide some sanity check command that could be used to detect malicious InRelease files such as 'find /var/lib/apt -name '*InRelease*' -size +2M' or so? The problem is, - debootstrap can only bootstrap from one source such as 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. (Correct me if I am wrong, I would hope to be wrong on that one.) - bootstrapping from 'http://security.debian.org' is not possible [contains only security updates, not a complete repository]. - So in conclusion one has a chance to get compromised when bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get upgrading from 'http://security.debian.org'. Is there any way to break this cycle? Best regards, Patrick [1] https://github.com/QubesOS/qubes-issues/issues/2520
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Idézem/Quoting Geert Stappers : On Thu, Dec 15, 2016 at 09:43:59PM +0100, SZÉPE Viktor wrote: Quoting Patrick Schleizer : >Very short summary of the bug: >(my own words) During apt-get upgrading signature verification can be >tricked resulting in arbitrary package installation, system compromise. > >- https://security-tracker.debian.org/tracker/CVE-2016-1252 >- https://www.debian.org/security/2016/dsa-3733 >- https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 > >How to upgrade from the insecure apt-get version 1.0.9.8.3 to the >patched apt-get version 1.0.9.8.4 without being compromised during that >upgrade? > You may download the new package http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb (for amd64) By the command wget http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb and check its checksum https://packages.debian.org/jessie/amd64/apt/download $ sha256sum apt_1.0.9.8.4_amd64.deb f40e51afbbcf2b1e23442c4c3df064a02ddc27bdfbfb155839577dcb1dedb74a Then the acual install sudo dpkg --install apt_1.0.9.8.4_amd64.deb Which might yield (due my test on a non-up-to-date-system) (Reading database ... 42686 files and directories currently installed.) Preparing to replace apt 1.0.9.8.4 (using apt_1.0.9.8.4_amd64.deb) ... Unpacking replacement apt ... dpkg: dependency problems prevent configuration of apt: apt depends on libapt-pkg4.12 (>= 1.0.9.8.4); however: Version of libapt-pkg4.12:amd64 on system is 0.9.7.9+deb7u6. apt depends on libc6 (>= 2.15); however: Version of libc6:amd64 on system is 2.13-38+deb7u8. apt depends on libstdc++6 (>= 4.9); however: Version of libstdc++6:amd64 on system is 4.7.2-5. dpkg: error processing apt (--install): dependency problems - leaving unconfigured Processing triggers for man-db ... Errors were encountered while processing: apt Version of libc6:amd64 on system is 2.13-38+deb7u8. Excuse me. I though you are using jessie. Please download the version for wheezy. https://security-tracker.debian.org/tracker/CVE-2016-1252 All the best! Viktor SZÉPE Viktor https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md -- +36-20-4242498 s...@szepe.net skype: szepe.viktor Budapest, III. kerület
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Geert Stappers: > On Thu, Dec 15, 2016 at 09:43:59PM +0100, SZÉPE Viktor wrote: >> Quoting Patrick Schleizer : >> >>> Very short summary of the bug: >>> (my own words) During apt-get upgrading signature verification can be >>> tricked resulting in arbitrary package installation, system compromise. >>> >>> - https://security-tracker.debian.org/tracker/CVE-2016-1252 >>> - https://www.debian.org/security/2016/dsa-3733 >>> - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 >>> >>> How to upgrade from the insecure apt-get version 1.0.9.8.3 to the >>> patched apt-get version 1.0.9.8.4 without being compromised during that >>> upgrade? >>> >> >> You may download the new package >> http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb >> (for amd64) > > By the command > > wget > http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb > > >> and check its checksum >> https://packages.debian.org/jessie/amd64/apt/download >> >> $ sha256sum apt_1.0.9.8.4_amd64.deb >> >> f40e51afbbcf2b1e23442c4c3df064a02ddc27bdfbfb155839577dcb1dedb74a >> > > Then the acual install > > sudo dpkg --install apt_1.0.9.8.4_amd64.deb > > Which might yield (due my test on a non-up-to-date-system) > > (Reading database ... 42686 files and directories currently installed.) > Preparing to replace apt 1.0.9.8.4 (using apt_1.0.9.8.4_amd64.deb) ... > Unpacking replacement apt ... > dpkg: dependency problems prevent configuration of apt: > apt depends on libapt-pkg4.12 (>= 1.0.9.8.4); however: > Version of libapt-pkg4.12:amd64 on system is 0.9.7.9+deb7u6. > apt depends on libc6 (>= 2.15); however: > Version of libc6:amd64 on system is 2.13-38+deb7u8. > apt depends on libstdc++6 (>= 4.9); however: > Version of libstdc++6:amd64 on system is 4.7.2-5. > > dpkg: error processing apt (--install): > dependency problems - leaving unconfigured > Processing triggers for man-db ... > Errors were encountered while processing: > apt > > > > > Groeten > Geert Stappers > Need to do this for all 'apt'ish packages. https://www.whonix.org/wiki/CVE-2016-1252
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Thu, Dec 15, 2016 at 09:43:59PM +0100, SZÉPE Viktor wrote: > Quoting Patrick Schleizer : > > >Very short summary of the bug: > >(my own words) During apt-get upgrading signature verification can be > >tricked resulting in arbitrary package installation, system compromise. > > > >- https://security-tracker.debian.org/tracker/CVE-2016-1252 > >- https://www.debian.org/security/2016/dsa-3733 > >- https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 > > > >How to upgrade from the insecure apt-get version 1.0.9.8.3 to the > >patched apt-get version 1.0.9.8.4 without being compromised during that > >upgrade? > > > > You may download the new package > http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb > (for amd64) By the command wget http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb > and check its checksum > https://packages.debian.org/jessie/amd64/apt/download > > $ sha256sum apt_1.0.9.8.4_amd64.deb > > f40e51afbbcf2b1e23442c4c3df064a02ddc27bdfbfb155839577dcb1dedb74a > Then the acual install sudo dpkg --install apt_1.0.9.8.4_amd64.deb Which might yield (due my test on a non-up-to-date-system) (Reading database ... 42686 files and directories currently installed.) Preparing to replace apt 1.0.9.8.4 (using apt_1.0.9.8.4_amd64.deb) ... Unpacking replacement apt ... dpkg: dependency problems prevent configuration of apt: apt depends on libapt-pkg4.12 (>= 1.0.9.8.4); however: Version of libapt-pkg4.12:amd64 on system is 0.9.7.9+deb7u6. apt depends on libc6 (>= 2.15); however: Version of libc6:amd64 on system is 2.13-38+deb7u8. apt depends on libstdc++6 (>= 4.9); however: Version of libstdc++6:amd64 on system is 4.7.2-5. dpkg: error processing apt (--install): dependency problems - leaving unconfigured Processing triggers for man-db ... Errors were encountered while processing: apt Groeten Geert Stappers -- Leven en laten leven
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
(Adding deity@l.d.o to the loop, so we actually get to see things
on the apt side)
Patrick Schleizer wrote:
> Is it possible to disable InRelease processing by apt-get?
Not really. What you could do is:
(1) use a proxy that rejects InRelease files; or
(2) look at the InRelease file and see if it contains crap
after you updated (if it looks OK, it's secure - you need
fairly long lines to be able to break this)
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
On Fri, Dec 16, 2016 at 4:33 AM, Patrick Schleizer wrote: > Is it possible to disable InRelease processing by apt-get? The answer from #debian-apt is that there is no setting for this. Your options are: Use an intercepting proxy that replies with 404 to InRelease files. Do an apt update to download InRelease/Release/Release.gpg using apt and then manually verify them with gpg before doing the upgrade. -- bye, pabs https://wiki.debian.org/PaulWise
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Hello Patrick! You may download the new package http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb (for amd64) and check its checksum https://packages.debian.org/jessie/amd64/apt/download $ sha256sum apt_1.0.9.8.4_amd64.deb f40e51afbbcf2b1e23442c4c3df064a02ddc27bdfbfb155839577dcb1dedb74a All the best to you! Idézem/Quoting Patrick Schleizer : TLDR: Is it possible to disable InRelease processing by apt-get? Long: Very short summary of the bug: (my own words) During apt-get upgrading signature verification can be tricked resulting in arbitrary package installation, system compromise. sources: - https://security-tracker.debian.org/tracker/CVE-2016-1252 - https://www.debian.org/security/2016/dsa-3733 - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 How to upgrade from the insecure apt-get version 1.0.9.8.3 to the patched apt-get version 1.0.9.8.4 without being compromised during that upgrade? Is it possible to disable InRelease processing by apt-get [for that upgrade or generally]? And have it check Release.gpg (which is provided anyway) instead? SZÉPE Viktor https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md -- +36-20-4242498 s...@szepe.net skype: szepe.viktor Budapest, III. kerület
not getting compromised while applying apt-get upgrade for CVE-2016-1252
TLDR: Is it possible to disable InRelease processing by apt-get? Long: Very short summary of the bug: (my own words) During apt-get upgrading signature verification can be tricked resulting in arbitrary package installation, system compromise. sources: - https://security-tracker.debian.org/tracker/CVE-2016-1252 - https://www.debian.org/security/2016/dsa-3733 - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 How to upgrade from the insecure apt-get version 1.0.9.8.3 to the patched apt-get version 1.0.9.8.4 without being compromised during that upgrade? Is it possible to disable InRelease processing by apt-get [for that upgrade or generally]? And have it check Release.gpg (which is provided anyway) instead?
