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

Groups > linux.debian.security > #5715 > unrolled thread

Re: debcheckroot v2.0 released

Back to article view | Back to linux.debian.security

Contents

  Re: debcheckroot v2.0 released Odo Poppinger <odopopp@gmail.com> - 2019-11-21 14:10 +0100
    Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-21 14:30 +0100
    Re: debcheckroot v2.0 released Elmar Stellnberger <estellnb@gmail.com> - 2019-11-25 22:20 +0100

#5715 — Re: debcheckroot v2.0 released

[Multipart message — attachments visible in raw view] — view raw

Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:

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.

Why not simply use sha256 - lists as can already be used and generated with
debcheckroot (as far as I have seen)? That would resolve the problem of a
possible infection of the host system running debcheckroot because there
are no archives that need to be unpacked when using plain sha256 file
lists. We would only need some official support by Debian for this, i.e.
someone who creates/updates these sha256 lists every time the updates
repository is updated and puts them online in a publicly known place.

[toc] | [next] | [standalone]

#5716

[Multipart message — attachments visible in raw view] — view raw

Am 21.11.19 um 13:59 schrieb Odo Poppinger:
> Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
>> 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.
>>
> Why not simply use sha256 - lists as can already be used and generated 
> with debcheckroot (as far as I have seen)? That would resolve the 
> problem of a possible infection of the host system running 
> debcheckroot because there are no archives that need to be unpacked 
> when using plain sha256 file lists. We would only need some official 
> support by Debian for this, i.e. someone who creates/updates these 
> sha256 lists every time the updates repository is updated and puts 
> them online in a publicly known place.

Yes, that is a very good idea!:

* debcheckroot with sha256-lists is considerably faster because it does 
not need to download and unpack all packages

* unknown/forgotten packages of elder versions could still be checked 
because the sha256sums are not forgotten

* You can generate sha256sums incrementally with debcheckroot, i.e. 
extend an existing list only for the new packages

[toc] | [prev] | [next] | [standalone]

#5724

[Multipart message — attachments visible in raw view] — view raw

Am 21.11.19 um 13:59 schrieb Odo Poppinger:

> Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
>> 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.
>>
> Why not simply use sha256 - lists as can already be used and generated 
> with debcheckroot (as far as I have seen)? That would resolve the 
> problem of a possible infection of the host system running 
> debcheckroot because there are no archives that need to be unpacked 
> when using plain sha256 file lists. We would only need some official 
> support by Debian for this, i.e. someone who creates/updates these 
> sha256 lists every time the updates repository is updated and puts 
> them online in a publicly known place.

   You can avoid an infection of the host system by generating 
sha256sums in one boot run with -t my.shalis --no-verify and use this on 
another boot with -u my.shalis --only --offline. I have now documented 
these options on the official webpage 
https://www.elstel.org/debcheckroot/. Options to download on a separate 
machine are also documented. Besides this I have revised the 
documentation as a whole so it may be worth reading it once more.

   Today in the evening I have released debcheckroot-v2.2. You may view 
all the updates at 
https://www.elstel.org/ViewRSS.php?ctgs=programs&lang=en or via 
https://www.elstel.org/ViewRSS.php?srcs=debcheckroot&lang=en

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web