Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5714

Re: debcheckroot v2.0 released

From Elmar Stellnberger <estellnb@gmail.com>
Newsgroups linux.debian.security
Subject Re: debcheckroot v2.0 released
Date 2019-11-20 12:30 +0100
Message-ID <z4wlk-6DB-3@gated-at.bofh.it> (permalink)
References (5 earlier) <yw4Uy-97-3@gated-at.bofh.it> <yycbg-wI-5@gated-at.bofh.it> <yymWZ-78w-1@gated-at.bofh.it> <z2Mue-7dA-9@gated-at.bofh.it> <z4aXv-1Jg-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

Am 19.11.19 um 13:29 schrieb Patrick Schleizer:
> Anyone using this yet?
>
> I would speculate, not many are using it. It needs step by step
> instructions. Otherwise, most users are lost at hello.

Well, I have a couple of downloads every day, the more serious ones with 
wget.

>
>> Things debcheckroot does not check at the moment are the initrd and
> the MBR (master boot record). You may unpack the initrd by hand and
> check the files contained there against a sha256sum list generated by
> debcheckroot. The MBR can first be backuped by confinedrv/diskutils.
> Then reinstall it with Grub from a fresh boot CD and look if the boot
> sector has altered. Under normal circumstances Grub would install the
> exactly same code into the MBR.
>
>
> I guess "nobody" is going to do that. Sounds complicated. And I am

The issue is that you do not need to check the initrd in deed under 
normal circumstances. If the initrd is infected so will be 
/sbin/mkinitramfs. I have never seen the initrd being infected alone as 
this would need to be updated on every new kernel configuration update 
like when you install firmware.

> [tor-dev] First-time tails/tor user feedback
>
> https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html
>
> Eliminating Stop-Points in the Installation and Use ofAnonymity Systems:
> a Usability Evaluation of the Tor Browser Bundle
>
> https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf
>
>
> I would also suggest a different design / additional feature. Rather
> than requiring a network connection or DVD, could you add a feature
> please similar to "apt-file" or "command-not-found"? What I mean by that:
>
> These tools download a cache while the system is running. debcheckroot
> could download/generate/prepare all the sha256 files on the disk. Yes,
> within the running system. Don't worry about verifying integrity of
> these files just yet. That will be answered later. Yes, these sha256
> files could be maliciously altered. But that is something you can check
> later at debcheckroot runtime.

What you suggest here does not make sense to me. If you have to check 
&regenerate these sha256 lists later on it is the same work as if you do 
not use them.

> Generating the (sha256) files required for later verification could be
> done using an apt or dpkg hook.

No, it is a feature of the tool that it does not require the dpkg 
infrastructure. - an important one. I have even successfully verified an 
old Debian6 installation with debcheckroot-v2.0. - no binaries required, 
only plain Python available almost everywhere.

> Then, later when debcheckroot runs, it would rely on these files. But to
> check that these files haven't been altered, it could check them against
> repository signing keys. So debcheckroot would need a bit root of trust
> built-in or better configurable. For example, it could be sufficient to
> point debcheckroot at clean Debian repository signing keys. These would
> then be used to check the sha256 files.

Key signatures are not trustworthy in general. I have argued this a 100 
times; see also https://www.elstel.org/software/GnuPG-usage.html.en

> The advantage of this would be that debcheckroot can be run from Live
> USD or Live DVD. Offline. No need for a network connection since all
> files to be verified would already be prepared.

debcheckroot can already perfectly run offline from the live cd of any 
distribution. I think you didn´t read the docs.

> To a rootkit hunter which laymen can use it's a long way to go. Some

debcheckroot is targeted at technically experienced users. No way to 
hunt rootkits authored by the NSA otherwise. You have to be a tough user 
to take this challenge! Well you can of course also use it for other 
kinds of rootkits by other governments or from criminals but 
interpreting the results requires some kind of knowledge about a Linux 
system. You need to know what the kernel is, what an initrd is, what you 
can find under /bin, /usr/bin, /sbin and /usr/sbin.

The tool has primarily been written against 5 eyes rootkits but I think 
it is still missing some features to take this challenge. f.i. it should 
be possible to unpack *.deb-s in an own boot run, separate from 
downloading and verification. That would shield against attacks targeted 
at the unpacking which affect the very system debcheckroot runs on. 
Supporting file only repos for customly downloaded and installed 
packages like my printer driver would also be an issue.

Once, the more people are using debcheckroot via Tails the harder it 
will get for intelligence to spoof these downloads. Effectiveness of 
debcheckroot is also an issue of a critical mass of users who apply the 
tool at least from time to time.

Most people do not take the threat posed by rootkits authored by western 
intelligence serious, though. I believe only a very few users are using 
Tails with --download-only as this was not well supported with 
debcheckroot-v2.0 but nobody had complained. It would have been possible 
to download via Tor using deblive linked from 
https://www.elstel.org/debcheckroot/ (https://www.elstel.org/deblive/) 
but I guess hardly anyone or nobody at all did. With debcheckroot-v2.1 
using Tails should be well supported, at least the way I do so. When you 
know that repository signing keys can be stolen (there is an own key 
stealing programme) things like 'torsocks apt-get update' can make sense.

> rhetorical question questions. How to I create a Live DVD / USB to check
> my running system? Download such a Live DVD / USB image somewhere? How

The serious user should have a Tails CD handy. At best buy that with a 
Linux magazine at your local newspaper kiosk. Downloading it insecurely 
directly via the internet may not be a good idea.

> do I mount the internal hard drive? Or mount an internal full disk
> encrypted disk? Then run debcheckroot on it? Could this be fully

I disadvise full disk encryption because you may easily loose your data. 
Better carry an M2 stick with you. Disk encryption can be cracked easily 
by installing a keylogger which will log the keyboard key strokes to get 
the encryption key.

> automated so these tests can be run routinely, easy? Graphical user
> interface? Run debcheckroot fully automated at boot (from read-only boot

You can not run that fully automatically as it needs a human being to 
analyse and interpret the results.

> medium such as Live DVD), verify all files, then continue booting from
> the internal disk (kexec)? That would be similar to the verified boot
> feature which is already a default feature in iPhone, Android, and ChromeOS.
>
> Can we get iPhone and Android Level Security for Linux Desktop
> Distributions?
I believe there is no security for Android and iPhone systems as you can 
not unmount and check the boot partition of these devices.
>> Dear readers of debian-security
>>
>>    I have just released debcheckroot-v2.0:
>> https://www.elstel.org/debcheckroot/
>>
>> The new tool can be used to check a Debian installation also against
>> previously unknown rootkits. It has many improvements towards
>> debcheckroot-v1.0:
>>
>> # usage of direct comparison or creation and usage of sha-256 lists
>> instead of the unsafe md5sums provided in the package header
>> # allow usage of multiple changeable media: i.e. DVD & BD-SL
>> verification rather than just BD-DL verification
>> # testing of symbolic links, of user, group and file-mode
>> # scanning the home directory for odd filenames that contain control
>> characters, on request: listing all hidden binary files in the home
>> directory
>> # download only mode + shuffling of download order for package download
>> via Tails/Tor and subsequent offline verification
>> # use of Python3 instead of Perl with built in support for tar, xzip,
>> gzip and bzip2; no more external helper programs required, works from
>> any live cd!
>>
>> Finally debcheckroot-v1.0 did no more work with current versions of
>> Debian as Debian now uses xzip instead of gzip. The new program supports
>> any of xzip, gzip and bz2 for compression of the data.tar.xz and the
>> controls .tar.xz inside the .deb ar-archive. Files are merely unpacked
>> in memory so debcheckroot keeps being quite efficient.
>>
>> I would be happy to discuss the new release here or to assist anyone who
>> wants to test the new tool!
>>
>> Regards,
>> Elmar
>>

Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Have I caught a firmware attack in the act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-13 09:40 +0200
  Re: Have I caught a firmware attack in the act? Or am I just paranoid? Paul Wise <pabs@debian.org> - 2019-08-14 07:10 +0200
  Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-14 17:40 +0200
    Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-15 23:20 +0200
      Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Davide Prina <davide.prina@gmail.com> - 2019-08-16 10:40 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? CMH <chouck@binghamton.edu> - 2019-08-16 14:20 +0200
        Re: Have I caught a firmware attack in the act? Or am I just paranoid? Andrei Grosu <andrei_grosu@fastmail.net> - 2019-08-16 19:20 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:20 +0200
      Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:10 +0200
      Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 19:30 +0200
      Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-16 21:20 +0200
        Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-17 11:50 +0200
          Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-17 13:20 +0200
            Re: Have I caught a firmware attack in the act? Or am I just  paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-23 09:30 +0200
              Re: Have I caught a firmware attack in the act? Or am I just  paranoid? Elmar Stellnberger <estellnb@gmail.com> - 2019-08-23 21:00 +0200
                debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-15 17:20 +0100
                Verified Boot, Secure Boot, dm-verity, debcheckroot Patrick Schleizer <adrelanos@riseup.net> - 2019-11-16 14:00 +0100
                Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:30 +0100
                Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Sylvain Beucler <beuc@beuc.net> - 2019-11-16 15:40 +0100
                Re: Verified Boot, Secure Boot, dm-verity, debcheckroot Elmar Stellnberger <estellnb@gmail.com> - 2019-11-16 15:40 +0100
                Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-19 13:40 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-20 12:30 +0100
                Re: debcheckroot v2.0 released Patrick Schleizer <adrelanos@riseup.net> - 2019-11-25 12:40 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-25 18:00 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-12-10 17:40 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-27 12:10 +0100
                Re: debcheckroot v2.0 released Cindy Sue Causey <butterflybytes@gmail.com> - 2020-01-17 14:40 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:00 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-01-17 17:20 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:20 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 20:50 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-04 21:00 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-23 17:10 +0100
                Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 04:40 +0100
                Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-24 11:20 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-24 15:50 +0100
                Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-03-25 03:00 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-25 11:30 +0100
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-03-26 11:10 +0100
                Re: debcheckroot v2.0 released "vince@vheuser.com" <vince@vheuser.com> - 2020-04-01 20:10 +0200
                Re: debcheckroot v2.0 released Paul Wise <pabs@debian.org> - 2020-04-02 02:00 +0200
                Re: debcheckroot v2.0 released Lewis Yarema <lewisyarema91@gmail.com> - 2020-04-02 11:20 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 17:00 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:40 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 16:50 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:50 +0200
                Re: debcheckroot v2.0 released William Gagnebé <william.gagnebe@gmail.com> - 2020-04-05 12:20 +0200
                Re: debcheckroot v2.0 released l0f4r0@tuta.io - 2020-04-05 12:30 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-07 17:50 +0200
                Re: debcheckroot v2.0 released "Niall O'Reilly" <Niall.oReilly+lists@no8.be> - 2020-04-02 18:30 +0200
                Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-02 21:00 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-02 21:40 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-03 13:50 +0200
                Re: debcheckroot v2.0 released Lee <ler762@gmail.com> - 2020-04-04 00:50 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@elstel.org> - 2020-04-04 09:40 +0200
                Re: debcheckroot v2.0 released Bjørn Mork <bjorn@mork.no> - 2020-04-14 09:30 +0200
                arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:40 +0200
                Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-04-25 15:50 +0200
                Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:00 +0200
                Re: arbitrary code execution on unformatted usb stick Elmar Stellnberger <estellnb@elstel.org> - 2020-05-02 17:10 +0200
                Fwd: Re: arbitrary code execution on unformatted usb stick estellnb@elstel.org - 2020-05-02 20:50 +0200
                Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2020-03-21 17:40 +0100
      Probably a false alarm Re: Have I caught a firmware attack in the  act? Or am I just paranoid? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-08-24 18:50 +0200

csiph-web