Re: debcheckroot v1.0 released
The tool is now ready to be downloaded at http://www.elstel.org/debcheckroot. Feedback will be highly appreciated! Am 28.01.2014 11:40, schrieb Elmar Stellnberger: Dear Debian-Security Having just released debcheckroot I wanna shortly present you my new tool: It was originally designed as a replacement for debsums and has the following qualities: * full support of Debian repos reading /etc/[apt/]sources.list to fetch checksums online * it can check a Debian installation remotely from any Unix-like system just requiring perl, gzip, bzip2 and tar * it does not require a chroot into or any tools of the installation to be checked; debcheckroot is thus the better choice when it comes to security (chroots may infect the freshly booted system); The checkroot family of programs has already proven to spot various rootkits not detected by chkrootkit and rkhunter * usage of checksums in the package header by default rather than locally stored ones (insecure if not backed up on f.i. an USB-stick); fast unpacking on the fly into memory without the creation of temporary files * nicely formatted output into files for later analysis … and all of that in just a 930 lines of code. Though debcheckroot is currently still licensed under S-FSL I am ready to re-publish under any license you like if you can at least promise me to maintain the necessary support infrastructure for it: * sha256sums rather than the bit old fashioned md5sums * checksums for all packages in the core distro (some are still missing md5sums) i.e. we would have to update debhelper to create shasums in addition to md5sums and enable this for all packages -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533fcf36.1030...@gmail.com
Re: debcheckroot v1.0 released
Great! I do really believe that Debian and other distros are currently lacking such a tool. Have you also thought about retrieving checksums from package headers? That is at least my approach because storing checksums spearately is a tedious task which the casual user is not likely up to take. My vision would be to just take any system from which you do not have rescued checksums in advance and check it for integrity and consistency with the package datababase. My choice was to implement it as a shell script (perl) so that it can be invoked from the rescue console of your installation medium i.e. from a clean system where you do not have a gcc or sth. else. Best Regards, Elmar Am 05.04.2014 10:20, schrieb Leslie S Satenstein: Hi Elmar Good morning.I have done something similar to you, but in a different way. I wrote my software in C language, Given any directory, scan every file in that directory and every sub-directory, and build a report file. Compare the report file to the previous scan. If there is a match, then there has been no change. I also include some filtering. For example, I could start at root and eliminate /dev /proc /tmp and /home. This would yield the /bin /usr, etc. etc. I could email you a sample scan of any directory tree. My basic scanner is version 1. I am working on a version 2, more sophisticated. Regards * Leslie * *Mr. Leslie Satenstein* *SENT FROM MY OPEN SOURCE LINUX SYSTEM.* ** *From:* Elmar Stellnberger estel...@gmail.com *To:* debian-security@lists.debian.org *Sent:* Saturday, April 5, 2014 5:39 AM *Subject:* Re: debcheckroot v1.0 released The tool is now ready to be downloaded at http://www.elstel.org/debcheckroot. Feedback will be highly appreciated! Am 28.01.2014 11:40, schrieb Elmar Stellnberger: Dear Debian-Security Having just released debcheckroot I wanna shortly present you my new tool: It was originally designed as a replacement for debsums and has the following qualities: * full support of Debian repos reading /etc/[apt/]sources.list to fetch checksums online * it can check a Debian installation remotely from any Unix-like system just requiring perl, gzip, bzip2 and tar * it does not require a chroot into or any tools of the installation to be checked; debcheckroot is thus the better choice when it comes to security (chroots may infect the freshly booted system); The checkroot family of programs has already proven to spot various rootkits not detected by chkrootkit and rkhunter * usage of checksums in the package header by default rather than locally stored ones (insecure if not backed up on f.i. an USB-stick); fast unpacking on the fly into memory without the creation of temporary files * nicely formatted output into files for later analysis … and all of that in just a 930 lines of code. Though debcheckroot is currently still licensed under S-FSL I am ready to re-publish under any license you like if you can at least promise me to maintain the necessary support infrastructure for it: * sha256sums rather than the bit old fashioned md5sums * checksums for all packages in the core distro (some are still missing md5sums) i.e. we would have to update debhelper to create shasums in addition to md5sums and enable this for all packages -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org mailto:debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org mailto:listmas...@lists.debian.org Archive: https://lists.debian.org/533fcf36.1030...@gmail.com
Re: debcheckroot v1.0 released
Hi Elmar! This is a most interesting tool! The opensuse logo on http://www.elstel.org/debcheckroot/ is confusing, since this is a Debian tool. This might scare of interested people. As Debian package headers do not use to be signed I think you are mistaken here or maybe I misunderstand. When you have a Debian medium you trust (such as a Live DVD from a trusted source), we can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as trusted. For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed by the Debian archive key. So when you run apt-get update followed by apt-get download $packagename, you get a package that is signed by Debian archive key. You can then unpack the package, create sha sums of all it's contents and then compare with the installed system. Sure, it's not perfect, but worth verifying this trust chain. It would be better/cleaner/simpler to implement this if Debian would publish signed sha sums files of all package contents. Lot's of opportunities to improve Debian in order to implement such a feature here. - I once attempted to write a script that can be run from a Live DVD to audit an installed Debian on hdd or to mount an image with Debian and to audit that. That script can be found here: https://github.com/Whonix/whonix-developer-meta-files/blob/master/deprecated_code/verify_build This approach seemed futile to me. At least for now. There are too many files, that are automatically generated created by postinst scripts. For example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically generated. Even worse, the file is non-deterministic. In future situation may improve: https://wiki.debian.org/ReproducibleBuilds It would also help if Debian had an OEM mode. Links to these discussions can be found here: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/10.html - For Whonix, Verifiable Builds have been implemented, which is similar to this tool: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/09.html As a maintainer of Whonix and interested in that feature, I am naturally interested in your tool. Why you should not use debsums Please don't be so harsh on debsums. It's not for backdoor detection, but great as a simple integrity check. Cheers, Patrick -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53401fdb.9010...@riseup.net
Re: debcheckroot v1.0 released
Am 05.04.2014 15:23, schrieb Patrick Schleizer:
Hi Elmar!
This is a most interesting tool!
The opensuse logo on http://www.elstel.org/debcheckroot/ is confusing,
since this is a Debian tool. This might scare of interested people.
Oh, what an embarrassing mishap!
Many Thanks for your evidence , Patrick.
As Debian package headers do not use to be signed
I think you are mistaken here or maybe I misunderstand. When you have a
Debian medium you trust (such as a Live DVD from a trusted source), we
can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as
trusted.
For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and
http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed
by the Debian archive key.
Ah, many thanks for that advice. I had just looked at the Release file
which was and still is not signed (am I right?! - have just checked this
file). However the InRelease file is signed and should contain all the
relevant information: a signature for every Packages.gz which in turn
does contain checksums for every package.
This approach seemed futile to me. At least for now. There are too many
files, that are automatically generated created by postinst scripts. For
example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically
generated. Even worse, the file is non-deterministic.
Well, of course debcheckroot is not a 'silver bullet' nor an ultimate
remedy.
However I have already used it to spot rootkits on some core binaries
and the glibc which did not hide in *.pyc or other files generated on
the fly.
You may see the files or more correct a superset of the packages that
had been altered that time when you look into the debcheckroot-script
for the $corepkgs variable. It should thus be already worth to use for
cases where you do not have self-created checksum lists; i.e. at least
for the casual user who does not want to afford higher security. As far
as that would only concern *.pyc one could even consider to remove all
these files if you think your system had been clean before the check
anyway so that you obtain a system which is clean with a considerable
high probability. At least the tool does not suffice without inspecting
all files which are listed as 'unchecked' by debcheckroot; so
auto-generated ascii files ought not matter as a little human effort to
inspect these files is presumed.
In future situation may improve:
https://wiki.debian.org/ReproducibleBuilds
Very pleased to hear from it.
It would also help if Debian had an OEM mode. Links to these discussions
can be found here:
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/10.html
-
For Whonix, Verifiable Builds have been implemented, which is similar to
this tool:
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/09.html
Very interesting. I will have a look on it shortly ...
As a maintainer of Whonix and interested in that feature, I am naturally
interested in your tool.
Great! Though maybe not suitable for a high security distro by the time
I believe the average user will for sure benefit.
If you or someone else would be interested to contribute re-licensing
under GPL should not be a problem at all.
I should have some time for the tool after the next week when my Easter
holidays will begin provided that sufficient interest is given.
Why you should not use debsums
Please don't be so harsh on debsums. It's not for backdoor detection,
but great as a simple integrity check.
Yes, perhaps you are right. However most people whom I know have not got
that, yet ('...').
Cheers,
Patrick
Best Regards,
Elmar
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534034cf.9070...@gmail.com
Re: debcheckroot v1.0 released
On Sat, 2014-04-05 at 16:52 +, Elmar Stellnberger wrote: Am 05.04.2014 15:23, schrieb Patrick Schleizer: As Debian package headers do not use to be signed I think you are mistaken here or maybe I misunderstand. When you have a Debian medium you trust (such as a Live DVD from a trusted source), we can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as trusted. For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed by the Debian archive key. Ah, many thanks for that advice. I had just looked at the Release file which was and still is not signed (am I right?! - have just checked this file). As the message you quoted says, there's a detached signature available in the same location. Regards, Adam -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396717255.2172.13.ca...@jacala.jungle.funky-badger.org
Re: debcheckroot v1.0 released
Ah; sometimes you oversee what is not hard to see; I am just updating the web page for debcheckroot; thx kind regards, Elmar. Am 05.04.2014 17:00, schrieb Adam D. Barratt: On Sat, 2014-04-05 at 16:52 +, Elmar Stellnberger wrote: Am 05.04.2014 15:23, schrieb Patrick Schleizer: As Debian package headers do not use to be signed I think you are mistaken here or maybe I misunderstand. When you have a Debian medium you trust (such as a Live DVD from a trusted source), we can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as trusted. For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed by the Debian archive key. Ah, many thanks for that advice. I had just looked at the Release file which was and still is not signed (am I right?! - have just checked this file). As the message you quoted says, there's a detached signature available in the same location. Regards, Adam -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534037d4.30...@gmail.com
Re: debcheckroot v1.0 released
Hi Patrick! Hi Adam! Am 05.04.2014 15:23, schrieb Patrick Schleizer: This approach seemed futile to me. At least for now. There are too many files, that are automatically generated created by postinst scripts. For example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically generated. Even worse, the file is non-deterministic. That is why the tool creates unchecked.lis a list of files which were not checked and which need a manual inspection (i.e. config files etc.). Sorry; I forgot to mention this before on my hastily published debcheckroot site. Again many thanks for your advice! Cheers Elmar p.s.: I have now updated the http://www.elstel.org/debcheckroot site a little. As Whonix uses Tor by default I wanted to ask you what you think about free VPN services like vpngate (as referenced by http://www.elstel.org/software)? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534042b2.5040...@gmail.com
Re: debcheckroot v1.0 released
Elmar Stellnberger:
As Debian package headers do not use to be signed
I think you are mistaken here or maybe I misunderstand. When you have a
Debian medium you trust (such as a Live DVD from a trusted source), we
can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as
trusted.
For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and
http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed
by the Debian archive key.
Ah, many thanks for that advice. I had just looked at the Release file
which was and still is not signed (am I right?! - have just checked this
file).
You can either directly use InRelease or what I find cleaner, verify
Release using Release.gpg.
However the InRelease file is signed and should contain all the
relevant information: a signature for every Packages.gz which in turn
does contain checksums for every package.
I think the goal is to keep (In)Release as small as possible to save
server load. But that is okay.
The (In)Release file authenticates the Packages (ex:
main/binary-i386/Packages). And the Packages file therefore contains a
signed [indirectly, but sufficient!] signature [sha sum] of all packages.
Ex:
Package: python-stem
...
Filename: pool/main/p/python-stem/python-stem_1.1.0-1_all.deb
...
SHA256: 4cdf5d54f230390452181007b0619fe7123328c95373feb73c7c4138a347a34e
...
And after extracting for example python-stem_1.1.0-1_all.deb, you can
create sha sums of it. Then compare. Sure, having a shasums file
downloadable and listed inside Packages file is a missing feature.
As far I can see, there are currently no breaches in the verification
chain. Sure, there is room for improvements, such as also checking
signatures against the maintainer, not just Debian archive key,
reproducible builds, random rebuilds checking against distributed
community (DHT) and more. Anyway, for purposes of debcheckroot, the
current verification methods should suffice.
This approach seemed futile to me. At least for now. There are too many
files, that are automatically generated created by postinst scripts. For
example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically
generated. Even worse, the file is non-deterministic.
Well, of course debcheckroot is not a 'silver bullet' nor an ultimate
remedy.
Sure. This wasn't meant as a criticism. I applaud you for writing this
tool! Because I already do imagine the future. When OEM mode and
reproducible builds become standard features, these are components and
debcheckroot is one component. debcheckroot will then become the 'silver
bullet'.
However I have already used it to spot rootkits on some core binaries
and the glibc which did not hide in *.pyc or other files generated on
the fly.
Sure.
As far
as that would only concern *.pyc one could even consider to remove all
these files
That will be difficult without OEM mode. There are loads of auto
generated files and loads of non-deterministic auto-generated files.
Anyway. This issue will be solved, when dpkg gets a reset to prestine
/ OEM feature.
Yes, perhaps you are right. However most people whom I know have not got
that, yet ('...').
I know. :) Because I once raised the question, if a tool such as
debcheckroot exists in Debian and debsums was recommended.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53404498.7000...@riseup.net
Re: [SECURITY] [DSA 2895-1] prosody security update
Hi, What about the prosody version in squeeze. Is it unaffected? If so, it may help to make it clear in the DSA. Warm regards and thanks for the good work, Tom On 06/04/14 01:10, Luciano Bello wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-2895-1 secur...@debian.org http://www.debian.org/security/ Luciano Bello April 06, 2014 http://www.debian.org/security/faq - - Package: prosody A denial-of-service vulnerability has been reported in Prosody, a XMPP server. If compression is enabled, an attacker might send highly-com- pressed XML elements (attack known as zip bomb) over XMPP streams and consume all the resources of the server. The SAX XML parser lua-expat is also affected by this issues. For the stable distribution (wheezy), this problem has been fixed in version 0.8.2-4+deb7u1 of prosody. For the unstable distribution (sid), this problem has been fixed in version 0.9.4-1 of prosody. For the stable distribution (wheezy), this problem has been fixed in version 1.2.0-5+deb7u1 of lua-expat. For the unstable distribution (sid), this problem has been fixed in version 1.3.0-1 lua-expat. We recommend that you upgrade your prosody and lua-expat packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTQI03AAoJEG7C3vaP/jd0YFIQAIZPBm3OfgC09T8G5m1sP+ER wcc/dV6Mm8Ldm3dXHpHRzAB5fds5LNPe2hmWsoa4QNkCLr0a2UHhnaf3wgHld1GU 6JGQBRGWA1IjS5fJotEVlOlLQZXxfNF9coajkAD0uUviUZYIt22XBmZRleHSrE4C RZAVgFrjR2dZPDqDB9Cgnb6WAsPSn+zgPmMikdqC74RLIpl1+A7q5D4apbGUHCFa kvID5E/V9SbfgVEN6F84XN5UbHprzGGF2RpNRGJUcNHcVGb/3CKWPNUg+BUDsbRL IgwLLwClTue/+Wv0UDnIe3VyQr6h2c9+2diaj5n0DebAKE3cPpknTrrfacb9U1kS J0NTrbEKH6XoggPTJPNRY1ut+kM4dVu0oYDV1nfGlGHBxmfM5GOMNKLBU+K79PFA hNP/5shfjt8PmEG27n2UdDJiAjmVF6rWc2gdtyFQNArBZHlx0+KxBnLLYlx48r09 6W5YGhlTfVKeG07DOCCqxBHi84CL6GJ0BFn4/sE6SQS+7bOSD4VYa+3xzThp7PQr q/7NWX1rHcRm3iScJUlapZB6Zg6DzwuBJ5QcpKdWFzmYOJfDwp/GQTp+ddrSmhdc JLcNO4M9mUjFJQuitfuJTGV2j36eehaZrDZ+iBnDquI5p6yQGP2tbL3S3VXPAQuM W0hdkefNVJrhJztQvvbj =SKLx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53409c53.8040...@gmx.net
Re: debcheckroot v1.0 released
On Sat, Apr 5, 2014 at 11:23 PM, Patrick Schleizer wrote: This approach seemed futile to me. At least for now. There are too many files, that are automatically generated created by postinst scripts. For example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically generated. Even worse, the file is non-deterministic. The cruft package has some explain scripts that can help suggest files to ignore. https://packages.debian.org/sid/cruft -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gk1parmbh-ckk02wywgghirkmzhvu+ut8upd7oeqh...@mail.gmail.com
