Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #5646 > unrolled thread
| Started by | "Rebecca N. Palmer" <rebecca_palmer@zoho.com> |
|---|---|
| First post | 2019-08-13 09:40 +0200 |
| Last post | 2019-08-24 18:50 +0200 |
| Articles | 20 on this page of 64 — 18 participants |
Back to article view | Back to linux.debian.security
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
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Patrick Schleizer <adrelanos@riseup.net> |
|---|---|
| Date | 2019-11-19 13:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <z4aXv-1Jg-3@gated-at.bofh.it> |
| In reply to | #5705 |
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. > 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 saying that as a fairly technical user. (Maintaining Debian derivative distributions...) Users need very detailed step-by-step instructions. This is my experience from over 7 years of Whonix user support. Murphy's law. Anything can go wrong, will go wrong. Keep it simple stupid (KISS). Some stuff on usability: Quote To Toggle, or not to Toggle: The End of Torbutton https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton > mike, am i completely anonymized if i log onto my facebook account? im using firefox 3.6 with tor and no script on windows 7 machine. thank you. Quote https://www.bbc.com/news/technology-20445632 > In order to make sure the mobile phone frequencies are not being tracked, I would fill up a washbasin with water and put the lid of a rice cooker over my head while I made a phone call," said one interviewee, a 28-year-old man who left the country in November 2010. [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. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. 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. 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 could be a Debian package that gets installed in the running system. And then starts preparing the sha256 files for later verification. It could also run the verification within the running system. That would just be an integrity check and no rootkit hunt. Since a system that is already running could be infected with a rootkit already. (Similar to debsums.) The same debcheckroot package then could also be used started from a Live USD or Live DVD and then "just" change the root (local of what debcheckroot should check) from the boot medium to the internal hard drive. debcheckroot could then verify that the existing sha256 files on the disk have valid signatures and if so, start the verification of all individual files. To a rootkit hunter which laymen can use it's a long way to go. Some 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 do I mount the internal hard drive? Or mount an internal full disk encrypted disk? Then run debcheckroot on it? Could this be fully automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot 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? https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions Cheers, Patrick Elmar Stellnberger: > 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 >
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2019-11-20 12:30 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <z4wlk-6DB-3@gated-at.bofh.it> |
| In reply to | #5712 |
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 ®enerate 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 >>
[toc] | [prev] | [next] | [standalone]
| From | Patrick Schleizer <adrelanos@riseup.net> |
|---|---|
| Date | 2019-11-25 12:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <z6kSJ-6z-3@gated-at.bofh.it> |
| In reply to | #5714 |
Elmar Stellnberger: >>> 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. Not necessarily. There are a lot more options to write a malicious initrd other than infecting /sbin/mkinitramfs. A rootkit could re-mount the real /sbin/mkinitramfs to a compromised hidden file /sbin/mkinitramfs, use LD_PRELOAD tricks and probably much more. > 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. How often did you see initrd being infected? >> 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 > ®enerate these sha256 lists later on it is the same work as if you do > not use them. Later on you don't have to re-generate the sha256 lists. Just verify their signatures. >> 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. Not using apt/dpkg comes at the expense of not being able to fully verify the whole system. What if there are outdated packages on the system which aren't available from anymore from repository? Using snapshot.debian.org? Also, for quickly repeatable verification it would be best to prepare as much as possible in background / during upgrade. Other tasks can be done at the same time. Then booting from read-only to debcheckroot purposes could safe a lot time. The less time it needs, the more it gets within reach to automate the process without sacrificing much boot time. Also by not using apt/dpkg, any packages downloaded would have to be gpg verified manually. I also don't see debcheckroot make use of gpg signature verification of downloaded files? Reinventing apt is difficult. See these attack on package managers: https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html Package metadata could be outdated. Downloaded package contents could be malicious or altered to pass verification. >> 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 That article https://www.elstel.org/software/GnuPG-usage.html.en starts with "How to use GnuPG securely". That isn't the best way to communicate "Key signatures are not trustworthy in general" which is a pretty broad claim. If "Key signatures are not trustworthy in general" then all apt package downloads could be considered compromised since APT relies on gnupg for verification. With that was true, and with mindset, and that being unfixable, we could as well as give up. >> To a rootkit hunter which laymen can use it's a long way to go. Some > > debcheckroot is targeted at technically experienced users. That's sad. Understood. > No way to > hunt rootkits authored by the NSA otherwise. Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. > 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. Why couldn't it be fully automated without manual interpretation needed? > 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. Usability and popularity. Both hard. Software is only step 1. >> 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. Full disk encryption is proven effective. If one travels and a bag gets stolen by a criminal, no data can be accessed. Keyloggers are really bad but unrelated from that. >> 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. Yes, Android has security features which are working fine, reliable, would be replicable on Linux desktops in principle, but aren't yet. That's the point of that writeup. https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions debcheckroot could help getting something like verified boot for Debian. Kind regards, Patrick
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2019-11-25 18:00 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <z6pSp-36r-7@gated-at.bofh.it> |
| In reply to | #5720 |
Am 25.11.19 um 12:35 schrieb Patrick Schleizer: > How often did you see initrd being infected? recently only once. So the attackers may change their vector; they have already done so multiple times. > Not using apt/dpkg comes at the expense of not being able to fully > verify the whole system. What if there are outdated packages on the > system which aren't available from anymore from repository? Using > snapshot.debian.org? I have just extended debcheckroot to also support file repos. Now it can check 100% of the packages I have installed. That was necessary because f.i. the printer driver is vendor specific and can not be fetched from an online repo. I will publish that as debcheckroot v2.2 soon. Outdated packages are a problem though; I have supposed that Debian would maintain sha256sums for packages not available online any more. However I do not see any good possibility to resolve this without support from the distributors. However I am not sure whether outdated updates would still be available on snapshot.debian.org; I would not believe so, though perhaps anyone else reading this list could help us. If it is not about updates but about singleton packages one could download specific packages from snapshot by hand if you really come across having installed such a package. > > Also, for quickly repeatable verification it would be best to prepare as > much as possible in background / during upgrade. Other tasks can be done > at the same time. Then booting from read-only to debcheckroot purposes > could safe a lot time. The less time it needs, the more it gets within > reach to automate the process without sacrificing much boot time. > > Also by not using apt/dpkg, any packages downloaded would have to be gpg > verified manually. > > I also don't see debcheckroot make use of gpg signature verification of > downloaded files? > > Reinventing apt is difficult. See these attack on package managers: > > https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html > > Package metadata could be outdated. Downloaded package contents could be > malicious or altered to pass verification. Yes, tor is no ultimate remedy to this. As long as there are little downloads anonymity may be compromised. The best way to shield against such attacks may be to first generate sha256sum lists in a singleton boot and then later on use them in another boot so that no malware from unpacking packages can persist in memory. However that is no remedy to altered package content. The only way I know to avoid this is to only install from blue ray media without using online updates. > That article https://www.elstel.org/software/GnuPG-usage.html.en starts > with "How to use GnuPG securely". That isn't the best way to communicate > "Key signatures are not trustworthy in general" which is a pretty broad > claim. > > If "Key signatures are not trustworthy in general" then all apt package > downloads could be considered compromised since APT relies on gnupg for > verification. With that was true, and with mindset, and that being > unfixable, we could as well as give up. Yes, that is what I presume. apt can install compromised updates. I know this is at least an attack vector for Windows. To repeat it I would at least doubt if not presume about any key which is stored online that it is compromised. Most times people connect with ssh to such machines and have a local certificate on the computer from which they connect. The certificate can be copied and the password will be keylogged. Only a very few people employ security strategies like switching keyboard and monitor to a computer where you do not web-browse or email. I have devices for that but most people don´t and as long as the distributors do not advertise it I presume that they do not follow such a strategy. Finally it would still be possible to get the key by physical access to that computer. I would also believe that for a distro like Debian this would pay of for intelligence services. To me personally I don´t have a defeatist mindset even not if the NSA/CIA or similar services are attacking me. They have once deleted the partition table on a computer used only offline to analyse some rootkit. Those who hack me also have physical access to my computers. There is no way for a defeatist mindset though as I can not let my human rights including that to live be violated. > >>> To a rootkit hunter which laymen can use it's a long way to go. Some >> debcheckroot is targeted at technically experienced users. > > That's sad. Understood. No it isn´t. People who care about security need to acquaint themselves with some basic facts on how the system they use is working. As it is Linux all the information should be available for the interested user. - and people do not only need to do so for use of debcheckroot. >> No way to >> hunt rootkits authored by the NSA otherwise. > > Yes, forget about NSA and alike. Let's not assume quasi-omnipotent > attackers. That leads to defeatist mindset which isn't productive. I have already commented on this. > Why couldn't it be fully automated without manual interpretation needed? That is not so easy to answer but an unsuspecting novice user simply will not be safe. There are just too many pitfalls. You do not need to know much but you need to understand some crucial facts to my believe. The thing why you can not automate this is that there is a hack for any automation how it can be bypassed. Whenever I have found something it was due to some unexpected action taken by me and not because the tools were so super. The NSA has a billion budget (correct me if someone knows the exact amount) and you won´t be smarter in programming than they are. > Usability and popularity. Both hard. Software is only step 1. > > Full disk encryption is proven effective. If one travels and a bag gets > stolen by a criminal, no data can be accessed. > > Keyloggers are really bad but unrelated from that. My attack scenarios always include key loggers. They are a too valuable tool for intelligence to miss this possibility. On the other hand my equipment hasn´t been stolen yet. Nonetheless anyone needs to know his enemies and what kind of attacks to shield against. > Yes, Android has security features which are working fine, reliable, > would be replicable on Linux desktops in principle, but aren't yet. > That's the point of that writeup. > > https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions > > debcheckroot could help getting something like verified boot for Debian. Well it is GPLv3. Anyone who would like to extend or develop it into some other direction is free to do so if he has enough energy and resources to do so. I hope I have sufficiently answered you questions and your points of discussion. If not simply re-ask.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2019-12-10 17:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zbQIi-6z7-5@gated-at.bofh.it> |
| In reply to | #5723 |
Am 25.11.19 um 17:52 schrieb Elmar Stellnberger: >> Not using apt/dpkg comes at the expense of not being able to fully >> verify the whole system. What if there are outdated packages on the >> system which aren't available from anymore from repository? Using >> snapshot.debian.org? > > I have just extended debcheckroot to also support file repos. Now it > can check 100% of the packages I have installed. That was necessary > because f.i. the printer driver is vendor specific and can not be > fetched from an online repo. I will publish that as debcheckroot v2.2 > soon. Outdated packages are a problem though; I have supposed that > Debian would maintain sha256sums for packages not available online any > more. However I do not see any good possibility to resolve this > without support from the distributors. However I am not sure whether > outdated updates would still be available on snapshot.debian.org; I > would not believe so, though perhaps anyone else reading this list > could help us. If it is not about updates but about singleton packages > one could download specific packages from snapshot by hand if you > really come across having installed such a package. > If debcheckroot can not find many packages that may point to an intentionally altered package database and thus to a possible infection of your system. I have seen many ways how to avoid scrutiny by debcheckroot in the past and this may just be an easy way to achieve this. Remember that with a freshly updated system + packages you downloaded manually, 100% of all packages should be verifiable. I do think of the theoretically constructed case that a package is still installed that is no more available via the update repo as rather improbable as normally the base version of all packages is available in the base repo. If a newer version is available in the update repo the update should have been installed as well.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2019-11-27 12:10 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <z73mN-3UW-1@gated-at.bofh.it> |
| In reply to | #5720 |
Am 25.11.19 um 12:35 schrieb Patrick Schleizer: > Yes, forget about NSA and alike. Let's not assume quasi-omnipotent > attackers. That leads to defeatist mindset which isn't productive. I would not let myself be defeated easily. Who has thought about emails in your inbox which are deleted before you can see them? Easily doable. They would just need to know your password. Or about outgoing emails which do not reach their target. As far as I have learnt to know it you can see them in the sent folder but they never appear on the other side, not even in the spam-box. The worse thing is however if someone wants to contact you and you do not even know about it, the other one just thinking you did not reply. The NSA & 5 Eyes are not just the most omni-potent but also the most-ubiquitous attackers so it should pay off trying to shield against them. There are as much unsuspecting users out there that you can not count. Shouldn´t we motivate them to check their machines? Sometimes it can be as easy as to sport executables in /bin which do not belong there and can normally be found in /usr/bin.
[toc] | [prev] | [next] | [standalone]
| From | Cindy Sue Causey <butterflybytes@gmail.com> |
|---|---|
| Date | 2020-01-17 14:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zpA0W-4rq-9@gated-at.bofh.it> |
| In reply to | #5726 |
On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: > > Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >> attackers. That leads to defeatist mindset which isn't productive. > > I would not let myself be defeated easily. Who has thought about > emails in your inbox which are deleted before you can see them? Easily > doable. They would just need to know your password. Or about outgoing > emails which do not reach their target. As far as I have learnt to know > it you can see them in the sent folder but they never appear on the > other side, not even in the spam-box. The worse thing is however if > someone wants to contact you and you do not even know about it, the > other one just thinking you did not reply. There have been two situations that, no, I can't name just this second, so this is anecdotal material *until I stumble back upon* the very real cases, BUT... Twice in the last maybe six months, there has been chatter about the receiving end's server(s) stopping the flow of incoming emails for unknown reasons. The occurrences were purely "glitches", NOT on purpose. It was either machine failure or accidentally Human-instigated mis-code or something that provoked the situations. End users found out when a sudden flood of sometimes OLD email suddenly hit their email inboxes. The last one was just in last few weeks. If and when I re-encounter that information, I'll post for posterity. :) As for the once formerly viewed and then now missing emails, been there, done there. Things being what they are in my own #Life, I've most definitely... "wondered" how the emails "disappeared" when they are NOT something I would have EVER deleted. It affects very few, less than a handful of correspondences. Sanity is found in realizing I have a VERY LARGE inbox.. and I'm surely just not using the right words for my queries. I've convinced myself that I'm using words that convey the same thoughts as the original messages but are not a search string-friendly match for the specific words that were originally written. :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-01-17 17:00 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zpCcq-5F7-7@gated-at.bofh.it> |
| In reply to | #5748 |
Hi Cindy Sue! Hi folks! I must confess there is little you can do about missing emails with debcheckroot. You can spot rootkits with hindsight but intelligence can also break in and go without leaving any trace. What would to my mind be necessary for a more secure email communication is a better penetration of DANE. Many CAs are known to issue rogue certificates to secret services so the public key is the only thing that may be trustworthy of a certificate. If that public key is signed and bound to a domain with DNSSEC (this is then called DANE) it shall be safe. I would guess that email dispatching was safe if encrypted and saved by DANE all the way to its target. F.i. it seems likely that intelligence just tries to halt email delivery if some suspicious email is in the queue until they have assessed what they wanna do about it. And it is questionable how those emails which seem to be sent successfully but which do not reach their target get lost. Something I as an end user can do about the emailing problem is to write and send my emails on a secure machine. If I am using webmail or an emailing program this requires to preconfigure certificates known to be safe and to only allow these. All CAs need to be disabled since the average user will never know which CAs issue rogue certificates. According to my knowledge any simple web page invocation immediately results in a cracked system if it is using a spoofed certificate which can not be excluded for any simple web search. Luckily my hoster provides DANE for the machines used for email delivery, webmailing and my website configuration panel. And I am still using a Debian 8 read only stick to boot such a secure system. Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as long as I only visit these two web pages of my hoster. Unfortunately newer versions of Firefox have a special implementation for so called HSTS (http strict transport security) certificates. You can not add a security exception for such a certificate but you need to configure all dependent certification authorities for such a certificate. However with the first CA you acknowledge you compromise your system`s security. Older versions of Firefox did not have this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 I am currently looking forward to test which versions of Debian 9 would work. Firefox from Debian 10 does no more work. If you have good luck your webmailing server supports DANE but does not use HSTS. Then you can use a current Debian. With Debian 8 you simply need to delete libnssckbi.so from libnss3 to disable all default CAs. You can not delete them by hand. If you do you need to mark every singleton CA but that does not prevent all deleted CAs to reappear a second after you have deleted them. That is why you needed to delete the .so. With newer versions of Firefox deleting libnssckbi.so does not stay without side effects: You can then not acknowledge security exceptions by hand any more. I have written a script to do that automatically though and I am likely to publish it at https://www.elstel.org/DANE/ in the future if sufficient interest is given in the issue. Once I know the last good Firefox version I could also approach to resolve the bug from above for newer Firefox versions. Unfortunately Dana Keeler has given this bug a resolved invalid so that it is unsure whether they would accept the bugfix upstreams. According to Dana`s comments the bug should in deed be marked as WONTFIX. That would be correct. If you like vote or comment for/on this bug. Elmar Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: > On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>> attackers. That leads to defeatist mindset which isn't productive. >> I would not let myself be defeated easily. Who has thought about >> emails in your inbox which are deleted before you can see them? Easily >> doable. They would just need to know your password. Or about outgoing >> emails which do not reach their target. As far as I have learnt to know >> it you can see them in the sent folder but they never appear on the >> other side, not even in the spam-box. The worse thing is however if >> someone wants to contact you and you do not even know about it, the >> other one just thinking you did not reply. > > There have been two situations that, no, I can't name just this > second, so this is anecdotal material *until I stumble back upon* the > very real cases, BUT... > > Twice in the last maybe six months, there has been chatter about the > receiving end's server(s) stopping the flow of incoming emails for > unknown reasons. The occurrences were purely "glitches", NOT on > purpose. It was either machine failure or accidentally > Human-instigated mis-code or something that provoked the situations. > > End users found out when a sudden flood of sometimes OLD email > suddenly hit their email inboxes. The last one was just in last few > weeks. If and when I re-encounter that information, I'll post for > posterity. :) > > As for the once formerly viewed and then now missing emails, been > there, done there. Things being what they are in my own #Life, I've > most definitely... "wondered" how the emails "disappeared" when they > are NOT something I would have EVER deleted. It affects very few, less > than a handful of correspondences. > > Sanity is found in realizing I have a VERY LARGE inbox.. and I'm > surely just not using the right words for my queries. I've convinced > myself that I'm using words that convey the same thoughts as the > original messages but are not a search string-friendly match for the > specific words that were originally written. :) > > Cindy :)
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-01-17 17:20 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zpCvL-60G-1@gated-at.bofh.it> |
| In reply to | #5749 |
The programs which I use for secure DANE web browsing should be uploaded at: https://www.elstel.org/DANE/ documentation follows later Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: > Hi Cindy Sue! Hi folks! > > I must confess there is little you can do about missing emails with > debcheckroot. You can spot rootkits with hindsight but intelligence > can also break in and go without leaving any trace. What would to my > mind be necessary for a more secure email communication is a better > penetration of DANE. Many CAs are known to issue rogue certificates to > secret services so the public key is the only thing that may be > trustworthy of a certificate. If that public key is signed and bound > to a domain with DNSSEC (this is then called DANE) it shall be safe. I > would guess that email dispatching was safe if encrypted and saved by > DANE all the way to its target. F.i. it seems likely that intelligence > just tries to halt email delivery if some suspicious email is in the > queue until they have assessed what they wanna do about it. And it is > questionable how those emails which seem to be sent successfully but > which do not reach their target get lost. > > Something I as an end user can do about the emailing problem is to > write and send my emails on a secure machine. If I am using webmail or > an emailing program this requires to preconfigure certificates known > to be safe and to only allow these. All CAs need to be disabled since > the average user will never know which CAs issue rogue certificates. > According to my knowledge any simple web page invocation immediately > results in a cracked system if it is using a spoofed certificate which > can not be excluded for any simple web search. Luckily my hoster > provides DANE for the machines used for email delivery, webmailing and > my website configuration panel. And I am still using a Debian 8 read > only stick to boot such a secure system. > > Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as > long as I only visit these two web pages of my hoster. Unfortunately > newer versions of Firefox have a special implementation for so called > HSTS (http strict transport security) certificates. You can not add a > security exception for such a certificate but you need to configure > all dependent certification authorities for such a certificate. > However with the first CA you acknowledge you compromise your system`s > security. Older versions of Firefox did not have this bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 > > I am currently looking forward to test which versions of Debian 9 > would work. Firefox from Debian 10 does no more work. If you have good > luck your webmailing server supports DANE but does not use HSTS. Then > you can use a current Debian. With Debian 8 you simply need to delete > libnssckbi.so from libnss3 to disable all default CAs. You can not > delete them by hand. If you do you need to mark every singleton CA but > that does not prevent all deleted CAs to reappear a second after you > have deleted them. That is why you needed to delete the .so. With > newer versions of Firefox deleting libnssckbi.so does not stay without > side effects: You can then not acknowledge security exceptions by hand > any more. I have written a script to do that automatically though and > I am likely to publish it at https://www.elstel.org/DANE/ in the > future if sufficient interest is given in the issue. Once I know the > last good Firefox version I could also approach to resolve the bug > from above for newer Firefox versions. Unfortunately Dana Keeler has > given this bug a resolved invalid so that it is unsure whether they > would accept the bugfix upstreams. According to Dana`s comments the > bug should in deed be marked as WONTFIX. That would be correct. If you > like vote or comment for/on this bug. > > Elmar > >
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-04 20:20 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zGHIK-rn-5@gated-at.bofh.it> |
| In reply to | #5749 |
Hi folks You can now download the indicated program at https://www.elstel.org/atea/ and read some documentation at https://www.elstel.org/DANE/. Kind Regards, Elmar Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: > Hi Cindy Sue! Hi folks! > > I must confess there is little you can do about missing emails with > debcheckroot. You can spot rootkits with hindsight but intelligence can > also break in and go without leaving any trace. What would to my mind be > necessary for a more secure email communication is a better penetration > of DANE. Many CAs are known to issue rogue certificates to secret > services so the public key is the only thing that may be trustworthy of > a certificate. If that public key is signed and bound to a domain with > DNSSEC (this is then called DANE) it shall be safe. I would guess that > email dispatching was safe if encrypted and saved by DANE all the way to > its target. F.i. it seems likely that intelligence just tries to halt > email delivery if some suspicious email is in the queue until they have > assessed what they wanna do about it. And it is questionable how those > emails which seem to be sent successfully but which do not reach their > target get lost. > > Something I as an end user can do about the emailing problem is to > write and send my emails on a secure machine. If I am using webmail or > an emailing program this requires to preconfigure certificates known to > be safe and to only allow these. All CAs need to be disabled since the > average user will never know which CAs issue rogue certificates. > According to my knowledge any simple web page invocation immediately > results in a cracked system if it is using a spoofed certificate which > can not be excluded for any simple web search. Luckily my hoster > provides DANE for the machines used for email delivery, webmailing and > my website configuration panel. And I am still using a Debian 8 read > only stick to boot such a secure system. > > Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as > long as I only visit these two web pages of my hoster. Unfortunately > newer versions of Firefox have a special implementation for so called > HSTS (http strict transport security) certificates. You can not add a > security exception for such a certificate but you need to configure all > dependent certification authorities for such a certificate. However with > the first CA you acknowledge you compromise your system`s security. > Older versions of Firefox did not have this bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 > > I am currently looking forward to test which versions of Debian 9 > would work. Firefox from Debian 10 does no more work. If you have good > luck your webmailing server supports DANE but does not use HSTS. Then > you can use a current Debian. With Debian 8 you simply need to delete > libnssckbi.so from libnss3 to disable all default CAs. You can not > delete them by hand. If you do you need to mark every singleton CA but > that does not prevent all deleted CAs to reappear a second after you > have deleted them. That is why you needed to delete the .so. With newer > versions of Firefox deleting libnssckbi.so does not stay without side > effects: You can then not acknowledge security exceptions by hand any > more. I have written a script to do that automatically though and I am > likely to publish it at https://www.elstel.org/DANE/ in the future if > sufficient interest is given in the issue. Once I know the last good > Firefox version I could also approach to resolve the bug from above for > newer Firefox versions. Unfortunately Dana Keeler has given this bug a > resolved invalid so that it is unsure whether they would accept the > bugfix upstreams. According to Dana`s comments the bug should in deed be > marked as WONTFIX. That would be correct. If you like vote or comment > for/on this bug. > > Elmar > > > Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: >> On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >>> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>>> attackers. That leads to defeatist mindset which isn't productive. >>> I would not let myself be defeated easily. Who has thought about >>> emails in your inbox which are deleted before you can see them? Easily >>> doable. They would just need to know your password. Or about outgoing >>> emails which do not reach their target. As far as I have learnt to know >>> it you can see them in the sent folder but they never appear on the >>> other side, not even in the spam-box. The worse thing is however if >>> someone wants to contact you and you do not even know about it, the >>> other one just thinking you did not reply. >> >> There have been two situations that, no, I can't name just this >> second, so this is anecdotal material *until I stumble back upon* the >> very real cases, BUT... >> >> Twice in the last maybe six months, there has been chatter about the >> receiving end's server(s) stopping the flow of incoming emails for >> unknown reasons. The occurrences were purely "glitches", NOT on >> purpose. It was either machine failure or accidentally >> Human-instigated mis-code or something that provoked the situations. >> >> End users found out when a sudden flood of sometimes OLD email >> suddenly hit their email inboxes. The last one was just in last few >> weeks. If and when I re-encounter that information, I'll post for >> posterity. :) >> >> As for the once formerly viewed and then now missing emails, been >> there, done there. Things being what they are in my own #Life, I've >> most definitely... "wondered" how the emails "disappeared" when they >> are NOT something I would have EVER deleted. It affects very few, less >> than a handful of correspondences. >> >> Sanity is found in realizing I have a VERY LARGE inbox.. and I'm >> surely just not using the right words for my queries. I've convinced >> myself that I'm using words that convey the same thoughts as the >> original messages but are not a search string-friendly match for the >> specific words that were originally written. :) >> >> Cindy :)
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-04 20:50 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zGIbL-B4-5@gated-at.bofh.it> |
| In reply to | #5758 |
It would be a question if anyone has tried to download a SHA512SUMS file from cdimage.debian.org with atea? As it turned out downloading this file with tails/tor is NOT sufficient. I have verified a Debian Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. Debcheckroot reported several infected packages like mkinitramfs, ispell and several pam-modules though mounting the squashfs may already have triggered some malware. Yours Sincerely Elmar Stellnberger Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: > Hi folks > > You can now download the indicated program at > https://www.elstel.org/atea/ and read some documentation at > https://www.elstel.org/DANE/. > > Kind Regards, > Elmar > > Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: >> Hi Cindy Sue! Hi folks! >> >> I must confess there is little you can do about missing emails with >> debcheckroot. You can spot rootkits with hindsight but intelligence >> can also break in and go without leaving any trace. What would to my >> mind be necessary for a more secure email communication is a better >> penetration of DANE. Many CAs are known to issue rogue certificates to >> secret services so the public key is the only thing that may be >> trustworthy of a certificate. If that public key is signed and bound >> to a domain with DNSSEC (this is then called DANE) it shall be safe. I >> would guess that email dispatching was safe if encrypted and saved by >> DANE all the way to its target. F.i. it seems likely that intelligence >> just tries to halt email delivery if some suspicious email is in the >> queue until they have assessed what they wanna do about it. And it is >> questionable how those emails which seem to be sent successfully but >> which do not reach their target get lost. >> >> Something I as an end user can do about the emailing problem is to >> write and send my emails on a secure machine. If I am using webmail or >> an emailing program this requires to preconfigure certificates known >> to be safe and to only allow these. All CAs need to be disabled since >> the average user will never know which CAs issue rogue certificates. >> According to my knowledge any simple web page invocation immediately >> results in a cracked system if it is using a spoofed certificate which >> can not be excluded for any simple web search. Luckily my hoster >> provides DANE for the machines used for email delivery, webmailing and >> my website configuration panel. And I am still using a Debian 8 read >> only stick to boot such a secure system. >> >> Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as >> long as I only visit these two web pages of my hoster. Unfortunately >> newer versions of Firefox have a special implementation for so called >> HSTS (http strict transport security) certificates. You can not add a >> security exception for such a certificate but you need to configure >> all dependent certification authorities for such a certificate. >> However with the first CA you acknowledge you compromise your system`s >> security. Older versions of Firefox did not have this bug: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 >> >> I am currently looking forward to test which versions of Debian 9 >> would work. Firefox from Debian 10 does no more work. If you have good >> luck your webmailing server supports DANE but does not use HSTS. Then >> you can use a current Debian. With Debian 8 you simply need to delete >> libnssckbi.so from libnss3 to disable all default CAs. You can not >> delete them by hand. If you do you need to mark every singleton CA but >> that does not prevent all deleted CAs to reappear a second after you >> have deleted them. That is why you needed to delete the .so. With >> newer versions of Firefox deleting libnssckbi.so does not stay without >> side effects: You can then not acknowledge security exceptions by hand >> any more. I have written a script to do that automatically though and >> I am likely to publish it at https://www.elstel.org/DANE/ in the >> future if sufficient interest is given in the issue. Once I know the >> last good Firefox version I could also approach to resolve the bug >> from above for newer Firefox versions. Unfortunately Dana Keeler has >> given this bug a resolved invalid so that it is unsure whether they >> would accept the bugfix upstreams. According to Dana`s comments the >> bug should in deed be marked as WONTFIX. That would be correct. If you >> like vote or comment for/on this bug. >> >> Elmar >> >> >> Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: >>> On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >>>> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>>>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>>>> attackers. That leads to defeatist mindset which isn't productive. >>>> I would not let myself be defeated easily. Who has thought about >>>> emails in your inbox which are deleted before you can see them? Easily >>>> doable. They would just need to know your password. Or about outgoing >>>> emails which do not reach their target. As far as I have learnt to know >>>> it you can see them in the sent folder but they never appear on the >>>> other side, not even in the spam-box. The worse thing is however if >>>> someone wants to contact you and you do not even know about it, the >>>> other one just thinking you did not reply. >>> >>> There have been two situations that, no, I can't name just this >>> second, so this is anecdotal material *until I stumble back upon* the >>> very real cases, BUT... >>> >>> Twice in the last maybe six months, there has been chatter about the >>> receiving end's server(s) stopping the flow of incoming emails for >>> unknown reasons. The occurrences were purely "glitches", NOT on >>> purpose. It was either machine failure or accidentally >>> Human-instigated mis-code or something that provoked the situations. >>> >>> End users found out when a sudden flood of sometimes OLD email >>> suddenly hit their email inboxes. The last one was just in last few >>> weeks. If and when I re-encounter that information, I'll post for >>> posterity. :) >>> >>> As for the once formerly viewed and then now missing emails, been >>> there, done there. Things being what they are in my own #Life, I've >>> most definitely... "wondered" how the emails "disappeared" when they >>> are NOT something I would have EVER deleted. It affects very few, less >>> than a handful of correspondences. >>> >>> Sanity is found in realizing I have a VERY LARGE inbox.. and I'm >>> surely just not using the right words for my queries. I've convinced >>> myself that I'm using words that convey the same thoughts as the >>> original messages but are not a search string-friendly match for the >>> specific words that were originally written. :) >>> >>> Cindy :)
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-04 21:00 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zGIls-Eo-7@gated-at.bofh.it> |
| In reply to | #5759 |
Hint: You can use -v to get a more verbose output if atea fails which includes the sha256 hash of the certificate (-vv would also be possible). From version 0.5 on atea should also do it without the --sys-keyfile option. For me atea succeeds with domains like mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like ssl-tools.net do already cause problems and my own domain www.elstel.org could sometimes be reached em ordem and sometimes not (see the two certificates in the https://www.elstel.org/DANE/ tar file which have the same start and ending date, one of them is a rogue certificate). The only domain where I have never succeeded is cdimage.debian.org. Is it permanently spoofed or did the Debian maintainers just enter a wrong hash in the TLSA record? Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: > It would be a question if anyone has tried to download a SHA512SUMS file > from cdimage.debian.org with atea? As it turned out downloading this > file with tails/tor is NOT sufficient. I have verified a Debian Live > 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. > Debcheckroot reported several infected packages like mkinitramfs, ispell > and several pam-modules though mounting the squashfs may already have > triggered some malware. > > Yours Sincerely > Elmar Stellnberger > > > > Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: >> Hi folks >> >> You can now download the indicated program at >> https://www.elstel.org/atea/ and read some documentation at >> https://www.elstel.org/DANE/. >> >> Kind Regards, >> Elmar >> >> Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: >>> Hi Cindy Sue! Hi folks! >>> >>> I must confess there is little you can do about missing emails >>> with debcheckroot. You can spot rootkits with hindsight but >>> intelligence can also break in and go without leaving any trace. What >>> would to my mind be necessary for a more secure email communication >>> is a better penetration of DANE. Many CAs are known to issue rogue >>> certificates to secret services so the public key is the only thing >>> that may be trustworthy of a certificate. If that public key is >>> signed and bound to a domain with DNSSEC (this is then called DANE) >>> it shall be safe. I would guess that email dispatching was safe if >>> encrypted and saved by DANE all the way to its target. F.i. it seems >>> likely that intelligence just tries to halt email delivery if some >>> suspicious email is in the queue until they have assessed what they >>> wanna do about it. And it is questionable how those emails which seem >>> to be sent successfully but which do not reach their target get lost. >>> >>> Something I as an end user can do about the emailing problem is >>> to write and send my emails on a secure machine. If I am using >>> webmail or an emailing program this requires to preconfigure >>> certificates known to be safe and to only allow these. All CAs need >>> to be disabled since the average user will never know which CAs issue >>> rogue certificates. According to my knowledge any simple web page >>> invocation immediately results in a cracked system if it is using a >>> spoofed certificate which can not be excluded for any simple web >>> search. Luckily my hoster provides DANE for the machines used for >>> email delivery, webmailing and my website configuration panel. And I >>> am still using a Debian 8 read only stick to boot such a secure system. >>> >>> Why the hell Debian 8? Isn`t that insecure? I believe it isn`t as >>> long as I only visit these two web pages of my hoster. Unfortunately >>> newer versions of Firefox have a special implementation for so called >>> HSTS (http strict transport security) certificates. You can not add a >>> security exception for such a certificate but you need to configure >>> all dependent certification authorities for such a certificate. >>> However with the first CA you acknowledge you compromise your >>> system`s security. Older versions of Firefox did not have this bug: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 >>> >>> I am currently looking forward to test which versions of Debian 9 >>> would work. Firefox from Debian 10 does no more work. If you have >>> good luck your webmailing server supports DANE but does not use HSTS. >>> Then you can use a current Debian. With Debian 8 you simply need to >>> delete libnssckbi.so from libnss3 to disable all default CAs. You can >>> not delete them by hand. If you do you need to mark every singleton >>> CA but that does not prevent all deleted CAs to reappear a second >>> after you have deleted them. That is why you needed to delete the >>> .so. With newer versions of Firefox deleting libnssckbi.so does not >>> stay without side effects: You can then not acknowledge security >>> exceptions by hand any more. I have written a script to do that >>> automatically though and I am likely to publish it at >>> https://www.elstel.org/DANE/ in the future if sufficient interest is >>> given in the issue. Once I know the last good Firefox version I could >>> also approach to resolve the bug from above for newer Firefox >>> versions. Unfortunately Dana Keeler has given this bug a resolved >>> invalid so that it is unsure whether they would accept the bugfix >>> upstreams. According to Dana`s comments the bug should in deed be >>> marked as WONTFIX. That would be correct. If you like vote or comment >>> for/on this bug. >>> >>> Elmar >>> >>> >>> Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: >>>> On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >>>>> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>>>>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>>>>> attackers. That leads to defeatist mindset which isn't productive. >>>>> I would not let myself be defeated easily. Who has thought about >>>>> emails in your inbox which are deleted before you can see them? Easily >>>>> doable. They would just need to know your password. Or about outgoing >>>>> emails which do not reach their target. As far as I have learnt to >>>>> know >>>>> it you can see them in the sent folder but they never appear on the >>>>> other side, not even in the spam-box. The worse thing is however if >>>>> someone wants to contact you and you do not even know about it, the >>>>> other one just thinking you did not reply. >>>> >>>> There have been two situations that, no, I can't name just this >>>> second, so this is anecdotal material *until I stumble back upon* the >>>> very real cases, BUT... >>>> >>>> Twice in the last maybe six months, there has been chatter about the >>>> receiving end's server(s) stopping the flow of incoming emails for >>>> unknown reasons. The occurrences were purely "glitches", NOT on >>>> purpose. It was either machine failure or accidentally >>>> Human-instigated mis-code or something that provoked the situations. >>>> >>>> End users found out when a sudden flood of sometimes OLD email >>>> suddenly hit their email inboxes. The last one was just in last few >>>> weeks. If and when I re-encounter that information, I'll post for >>>> posterity. :) >>>> >>>> As for the once formerly viewed and then now missing emails, been >>>> there, done there. Things being what they are in my own #Life, I've >>>> most definitely... "wondered" how the emails "disappeared" when they >>>> are NOT something I would have EVER deleted. It affects very few, less >>>> than a handful of correspondences. >>>> >>>> Sanity is found in realizing I have a VERY LARGE inbox.. and I'm >>>> surely just not using the right words for my queries. I've convinced >>>> myself that I'm using words that convey the same thoughts as the >>>> original messages but are not a search string-friendly match for the >>>> specific words that were originally written. :) >>>> >>>> Cindy :)
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-04 21:00 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zGIlt-Eo-15@gated-at.bofh.it> |
| In reply to | #5760 |
If anyone wants to play with atea use it under GPLv3. I forgot to add the license header in the file but this email should entitle you to use the program under GPLv3. Elmar Am 04.03.20 um 20:51 schrieb Elmar Stellnberger: > Hint: You can use -v to get a more verbose output if atea fails which > includes the sha256 hash of the certificate (-vv would also be > possible). From version 0.5 on atea should also do it without the > --sys-keyfile option. For me atea succeeds with domains like > mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like > ssl-tools.net do already cause problems and my own domain www.elstel.org > could sometimes be reached em ordem and sometimes not (see the two > certificates in the https://www.elstel.org/DANE/ tar file which have the > same start and ending date, one of them is a rogue certificate). The > only domain where I have never succeeded is cdimage.debian.org. Is it > permanently spoofed or did the Debian maintainers just enter a wrong > hash in the TLSA record? > > Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: >> It would be a question if anyone has tried to download a SHA512SUMS >> file from cdimage.debian.org with atea? As it turned out downloading >> this file with tails/tor is NOT sufficient. I have verified a Debian >> Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. >> Debcheckroot reported several infected packages like mkinitramfs, >> ispell and several pam-modules though mounting the squashfs may >> already have triggered some malware. >> >> Yours Sincerely >> Elmar Stellnberger >> >> >> >> Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: >>> Hi folks >>> >>> You can now download the indicated program at >>> https://www.elstel.org/atea/ and read some documentation at >>> https://www.elstel.org/DANE/. >>> >>> Kind Regards, >>> Elmar >>> >>> Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: >>>> Hi Cindy Sue! Hi folks! >>>> >>>> I must confess there is little you can do about missing emails >>>> with debcheckroot. You can spot rootkits with hindsight but >>>> intelligence can also break in and go without leaving any trace. >>>> What would to my mind be necessary for a more secure email >>>> communication is a better penetration of DANE. Many CAs are known to >>>> issue rogue certificates to secret services so the public key is the >>>> only thing that may be trustworthy of a certificate. If that public >>>> key is signed and bound to a domain with DNSSEC (this is then called >>>> DANE) it shall be safe. I would guess that email dispatching was If >>>> safe if encrypted and saved by DANE all the way to its target. F.i. >>>> it seems likely that intelligence just tries to halt email delivery >>>> if some suspicious email is in the queue until they have assessed >>>> what they wanna do about it. And it is questionable how those emails >>>> which seem to be sent successfully but which do not reach their >>>> target get lost. >>>> >>>> Something I as an end user can do about the emailing problem is >>>> to write and send my emails on a secure machine. If I am using >>>> webmail or an emailing program this requires to preconfigure >>>> certificates known to be safe and to only allow these. All CAs need >>>> to be disabled since the average user will never know which CAs >>>> issue rogue certificates. According to my knowledge any simple web >>>> page invocation immediately results in a cracked system if it is >>>> using a spoofed certificate which can not be excluded for any simple >>>> web search. Luckily my hoster provides DANE for the machines used >>>> for email delivery, webmailing and my website configuration panel. >>>> And I am still using a Debian 8 read only stick to boot such a >>>> secure system. >>>> >>>> Why the hell Debian 8? Isn`t that insecure? I believe it isn`t >>>> as long as I only visit these two web pages of my hoster. >>>> Unfortunately newer versions of Firefox have a special >>>> implementation for so called HSTS (http strict transport security) >>>> certificates. You can not add a security exception for such a >>>> certificate but you need to configure all dependent certification >>>> authorities for such a certificate. However with the first CA you >>>> acknowledge you compromise your system`s security. Older versions of >>>> Firefox did not have this bug: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 >>>> >>>> I am currently looking forward to test which versions of Debian 9 >>>> would work. Firefox from Debian 10 does no more work. If you have >>>> good luck your webmailing server supports DANE but does not use >>>> HSTS. Then you can use a current Debian. With Debian 8 you simply >>>> need to delete libnssckbi.so from libnss3 to disable all default >>>> CAs. You can not delete them by hand. If you do you need to mark >>>> every singleton CA but that does not prevent all deleted CAs to >>>> reappear a second after you have deleted them. That is why you >>>> needed to delete the .so. With newer versions of Firefox deleting >>>> libnssckbi.so does not stay without side effects: You can then not >>>> acknowledge security exceptions by hand any more. I have written a >>>> script to do that automatically though and I am likely to publish it >>>> at https://www.elstel.org/DANE/ in the future if sufficient interest >>>> is given in the issue. Once I know the last good Firefox version I >>>> could also approach to resolve the bug from above for newer Firefox >>>> versions. Unfortunately Dana Keeler has given this bug a resolved >>>> invalid so that it is unsure whether they would accept the bugfix >>>> upstreams. According to Dana`s comments the bug should in deed be >>>> marked as WONTFIX. That would be correct. If you like vote or >>>> comment for/on this bug. >>>> >>>> Elmar >>>> >>>> >>>> Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: >>>>> On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >>>>>> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>>>>>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>>>>>> attackers. That leads to defeatist mindset which isn't productive. >>>>>> I would not let myself be defeated easily. Who has thought about >>>>>> emails in your inbox which are deleted before you can see them? >>>>>> Easily >>>>>> doable. They would just need to know your password. Or about outgoing >>>>>> emails which do not reach their target. As far as I have learnt to >>>>>> know >>>>>> it you can see them in the sent folder but they never appear on the >>>>>> other side, not even in the spam-box. The worse thing is however if >>>>>> someone wants to contact you and you do not even know about it, the >>>>>> other one just thinking you did not reply. >>>>> >>>>> There have been two situations that, no, I can't name just this >>>>> second, so this is anecdotal material *until I stumble back upon* the >>>>> very real cases, BUT... >>>>> >>>>> Twice in the last maybe six months, there has been chatter about the >>>>> receiving end's server(s) stopping the flow of incoming emails for >>>>> unknown reasons. The occurrences were purely "glitches", NOT on >>>>> purpose. It was either machine failure or accidentally >>>>> Human-instigated mis-code or something that provoked the situations. >>>>> >>>>> End users found out when a sudden flood of sometimes OLD email >>>>> suddenly hit their email inboxes. The last one was just in last few >>>>> weeks. If and when I re-encounter that information, I'll post for >>>>> posterity. :) >>>>> >>>>> As for the once formerly viewed and then now missing emails, been >>>>> there, done there. Things being what they are in my own #Life, I've >>>>> most definitely... "wondered" how the emails "disappeared" when they >>>>> are NOT something I would have EVER deleted. It affects very few, less >>>>> than a handful of correspondences. >>>>> >>>>> Sanity is found in realizing I have a VERY LARGE inbox.. and I'm >>>>> surely just not using the right words for my queries. I've convinced >>>>> myself that I'm using words that convey the same thoughts as the >>>>> original messages but are not a search string-friendly match for the >>>>> specific words that were originally written. :) >>>>> >>>>> Cindy :) >
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@gmail.com> |
|---|---|
| Date | 2020-03-23 17:10 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zNxOi-2Z2-7@gated-at.bofh.it> |
| In reply to | #5761 |
[Multipart message — attachments visible in raw view] — view raw
I have just released a̅tea v0.6: https://www.elstel.org/atea/ . It now implements SNI (Server Name Indication) and can thus also be successfully used to download files like my public gpg key from elstel.org. atea tii-cert -rv https://cdimage.debian.org TLSA record (first three bytes are for TLSA-mode): 03:01:01:0c:8e:2d:2b:49:50:6b:cc:77:f7:70:5d:ee:69:fe:a2:30:93:55:5e:88:a2:68:4c:79:8b:8c:e1:84:2b:32:6f hash of the server certificate: 7d:86:1f:c8:c6:d0:54:ec:74:81:3e:c4:0d:7e:14:45:50:1f:0d:0a:50:11:f1:44:bf:85:cc:6e:2f:8f:cd:ee certificate signature in TLSA record did not match (https://cdimage.debian.org) server cert written to 'cdimage.debian.org-rogue.pem'. The only site which is still making problems is cdimage.debian.org. Could any good Christ from the Debian community have a look at this issue. The server maintainers would need to complain about the rogue cert! Am 04.03.20 um 20:57 schrieb Elmar Stellnberger: > If anyone wants to play with atea use it under GPLv3. I forgot to add > the license header in the file but this email should entitle you to use > the program under GPLv3. > > Elmar > > Am 04.03.20 um 20:51 schrieb Elmar Stellnberger: >> Hint: You can use -v to get a more verbose output if atea fails which >> includes the sha256 hash of the certificate (-vv would also be >> possible). From version 0.5 on atea should also do it without the >> --sys-keyfile option. For me atea succeeds with domains like >> mail.dotplex.com, secure.dotplex.de or web4.dotplex.com. Pages like >> ssl-tools.net do already cause problems and my own domain >> www.elstel.org could sometimes be reached em ordem and sometimes not >> (see the two certificates in the https://www.elstel.org/DANE/ tar file >> which have the same start and ending date, one of them is a rogue >> certificate). The only domain where I have never succeeded is >> cdimage.debian.org. Is it permanently spoofed or did the Debian >> maintainers just enter a wrong hash in the TLSA record? >> >> Am 04.03.20 um 20:41 schrieb Elmar Stellnberger: >>> It would be a question if anyone has tried to download a SHA512SUMS >>> file from cdimage.debian.org with atea? As it turned out downloading >>> this file with tails/tor is NOT sufficient. I have verified a Debian >>> Live 10.1.0 DVD image against the Debian 10.1.0 Install BD-DL I have. >>> Debcheckroot reported several infected packages like mkinitramfs, >>> ispell and several pam-modules though mounting the squashfs may >>> already have triggered some malware. >>> >>> Yours Sincerely >>> Elmar Stellnberger >>> >>> >>> >>> Am 04.03.20 um 20:04 schrieb Elmar Stellnberger: >>>> Hi folks >>>> >>>> You can now download the indicated program at >>>> https://www.elstel.org/atea/ and read some documentation at >>>> https://www.elstel.org/DANE/. >>>> >>>> Kind Regards, >>>> Elmar >>>> >>>> Am 17.01.20 um 16:52 schrieb Elmar Stellnberger: >>>>> Hi Cindy Sue! Hi folks! >>>>> >>>>> I must confess there is little you can do about missing emails >>>>> with debcheckroot. You can spot rootkits with hindsight but >>>>> intelligence can also break in and go without leaving any trace. >>>>> What would to my mind be necessary for a more secure email >>>>> communication is a better penetration of DANE. Many CAs are known >>>>> to issue rogue certificates to secret services so the public key is >>>>> the only thing that may be trustworthy of a certificate. If that >>>>> public key is signed and bound to a domain with DNSSEC (this is >>>>> then called DANE) it shall be safe. I would guess that email >>>>> dispatching was If safe if encrypted and saved by DANE all the way >>>>> to its target. F.i. it seems likely that intelligence just tries to >>>>> halt email delivery if some suspicious email is in the queue until >>>>> they have assessed what they wanna do about it. And it is >>>>> questionable how those emails which seem to be sent successfully >>>>> but which do not reach their target get lost. >>>>> >>>>> Something I as an end user can do about the emailing problem is >>>>> to write and send my emails on a secure machine. If I am using >>>>> webmail or an emailing program this requires to preconfigure >>>>> certificates known to be safe and to only allow these. All CAs need >>>>> to be disabled since the average user will never know which CAs >>>>> issue rogue certificates. According to my knowledge any simple web >>>>> page invocation immediately results in a cracked system if it is >>>>> using a spoofed certificate which can not be excluded for any >>>>> simple web search. Luckily my hoster provides DANE for the machines >>>>> used for email delivery, webmailing and my website configuration >>>>> panel. And I am still using a Debian 8 read only stick to boot such >>>>> a secure system. >>>>> >>>>> Why the hell Debian 8? Isn`t that insecure? I believe it isn`t >>>>> as long as I only visit these two web pages of my hoster. >>>>> Unfortunately newer versions of Firefox have a special >>>>> implementation for so called HSTS (http strict transport security) >>>>> certificates. You can not add a security exception for such a >>>>> certificate but you need to configure all dependent certification >>>>> authorities for such a certificate. However with the first CA you >>>>> acknowledge you compromise your system`s security. Older versions >>>>> of Firefox did not have this bug: >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1606802 >>>>> >>>>> I am currently looking forward to test which versions of Debian >>>>> 9 would work. Firefox from Debian 10 does no more work. If you have >>>>> good luck your webmailing server supports DANE but does not use >>>>> HSTS. Then you can use a current Debian. With Debian 8 you simply >>>>> need to delete libnssckbi.so from libnss3 to disable all default >>>>> CAs. You can not delete them by hand. If you do you need to mark >>>>> every singleton CA but that does not prevent all deleted CAs to >>>>> reappear a second after you have deleted them. That is why you >>>>> needed to delete the .so. With newer versions of Firefox deleting >>>>> libnssckbi.so does not stay without side effects: You can then not >>>>> acknowledge security exceptions by hand any more. I have written a >>>>> script to do that automatically though and I am likely to publish >>>>> it at https://www.elstel.org/DANE/ in the future if sufficient >>>>> interest is given in the issue. Once I know the last good Firefox >>>>> version I could also approach to resolve the bug from above for >>>>> newer Firefox versions. Unfortunately Dana Keeler has given this >>>>> bug a resolved invalid so that it is unsure whether they would >>>>> accept the bugfix upstreams. According to Dana`s comments the bug >>>>> should in deed be marked as WONTFIX. That would be correct. If you >>>>> like vote or comment for/on this bug. >>>>> >>>>> Elmar >>>>> >>>>> >>>>> Am 17.01.20 um 14:29 schrieb Cindy Sue Causey: >>>>>> On 11/27/19, Elmar Stellnberger <estellnb@gmail.com> wrote: >>>>>>> Am 25.11.19 um 12:35 schrieb Patrick Schleizer: >>>>>>>> Yes, forget about NSA and alike. Let's not assume quasi-omnipotent >>>>>>>> attackers. That leads to defeatist mindset which isn't productive. >>>>>>> I would not let myself be defeated easily. Who has thought about >>>>>>> emails in your inbox which are deleted before you can see them? >>>>>>> Easily >>>>>>> doable. They would just need to know your password. Or about >>>>>>> outgoing >>>>>>> emails which do not reach their target. As far as I have learnt >>>>>>> to know >>>>>>> it you can see them in the sent folder but they never appear on the >>>>>>> other side, not even in the spam-box. The worse thing is however if >>>>>>> someone wants to contact you and you do not even know about it, the >>>>>>> other one just thinking you did not reply. >>>>>> >>>>>> There have been two situations that, no, I can't name just this >>>>>> second, so this is anecdotal material *until I stumble back upon* the >>>>>> very real cases, BUT... >>>>>> >>>>>> Twice in the last maybe six months, there has been chatter about the >>>>>> receiving end's server(s) stopping the flow of incoming emails for >>>>>> unknown reasons. The occurrences were purely "glitches", NOT on >>>>>> purpose. It was either machine failure or accidentally >>>>>> Human-instigated mis-code or something that provoked the situations. >>>>>> >>>>>> End users found out when a sudden flood of sometimes OLD email >>>>>> suddenly hit their email inboxes. The last one was just in last few >>>>>> weeks. If and when I re-encounter that information, I'll post for >>>>>> posterity. :) >>>>>> >>>>>> As for the once formerly viewed and then now missing emails, been >>>>>> there, done there. Things being what they are in my own #Life, I've >>>>>> most definitely... "wondered" how the emails "disappeared" when they >>>>>> are NOT something I would have EVER deleted. It affects very few, >>>>>> less >>>>>> than a handful of correspondences. >>>>>> >>>>>> Sanity is found in realizing I have a VERY LARGE inbox.. and I'm >>>>>> surely just not using the right words for my queries. I've convinced >>>>>> myself that I'm using words that convey the same thoughts as the >>>>>> original messages but are not a search string-friendly match for the >>>>>> specific words that were originally written. :) >>>>>> >>>>>> Cindy :) >>
[toc] | [prev] | [next] | [standalone]
| From | Paul Wise <pabs@debian.org> |
|---|---|
| Date | 2020-03-24 04:40 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zNIA1-16j-1@gated-at.bofh.it> |
| In reply to | #5776 |
On Mon, Mar 23, 2020 at 4:00 PM Elmar Stellnberger wrote: > The only site which is still making problems is cdimage.debian.org. > Could any good Christ from the Debian community have a look at this > issue. The server maintainers would need to complain about the rogue cert! I've forwarded this to the Debian sysadmins IRC channel. I think it is related to the fact that the cdimage.d.o server is not managed by the Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to get certs, and then of course the TLSA records got outdated after the renewal. For other debian.org domains that are not managed by the Debian sysadmins, we centrally create the certs and propagate them to external services (like the CDNs for deb.d.o). The cdimage.d.o server isn't a CDN and probably doesn't have cert APIs but we can probably use the same approach to fix this. -- bye, pabs https://wiki.debian.org/PaulWise
[toc] | [prev] | [next] | [standalone]
| From | Paul Wise <pabs@debian.org> |
|---|---|
| Date | 2020-03-24 11:20 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zNOP8-51F-5@gated-at.bofh.it> |
| In reply to | #5777 |
On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote: > I've forwarded this to the Debian sysadmins IRC channel. I think it is > related to the fact that the cdimage.d.o server is not managed by the > Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to > get certs, and then of course the TLSA records got outdated after the > renewal. For other debian.org domains that are not managed by the > Debian sysadmins, we centrally create the certs and propagate them to > external services (like the CDNs for deb.d.o). The cdimage.d.o server > isn't a CDN and probably doesn't have cert APIs but we can probably > use the same approach to fix this. The result was that the mismatch was caused by a bug in the Debian sysadmin puppet. The fix was to remove the TLSA records for this domain due to the aforementioned management disconnect. If the cert management for cdimage.d.o changes to the deb.d.o setup then the TLSA records will return and be correct. -- bye, pabs https://wiki.debian.org/PaulWise
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-03-24 15:50 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zNT2s-7uc-37@gated-at.bofh.it> |
| In reply to | #5779 |
Am 24.03.20 um 11:18 schrieb Paul Wise: > On Tue, Mar 24, 2020 at 3:33 AM Paul Wise wrote: > >> I've forwarded this to the Debian sysadmins IRC channel. I think it is >> related to the fact that the cdimage.d.o server is not managed by the >> Debian sysadmins, so the UMU ACC admins probably used Lets Encrypt to >> get certs, and then of course the TLSA records got outdated after the >> renewal. For other debian.org domains that are not managed by the >> Debian sysadmins, we centrally create the certs and propagate them to >> external services (like the CDNs for deb.d.o). The cdimage.d.o server >> isn't a CDN and probably doesn't have cert APIs but we can probably >> use the same approach to fix this. > > The result was that the mismatch was caused by a bug in the Debian > sysadmin puppet. The fix was to remove the TLSA records for this > domain due to the aforementioned management disconnect. If the cert > management for cdimage.d.o changes to the deb.d.o setup then the TLSA > records will return and be correct. > I hope this is gonna happen anytime soon. DANE and thus a valid TLSA record is of very high value and importance for getting a genuine download of Debian. As I have mentioned before downloads via Tor can be spoofed like my last Debian Live 10 download which turned out to be infected by debchecheckrooting against the Debian 10 DL-BD.
[toc] | [prev] | [next] | [standalone]
| From | Paul Wise <pabs@debian.org> |
|---|---|
| Date | 2020-03-25 03:00 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zO3uN-5qI-5@gated-at.bofh.it> |
| In reply to | #5780 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote: > I hope this is gonna happen anytime soon. DANE and thus a valid TLSA > record is of very high value and importance for getting a genuine > download of Debian. As I have mentioned before downloads via Tor can be > spoofed like my last Debian Live 10 download which turned out to be > infected by debchecheckrooting against the Debian 10 DL-BD. TBH, very few people care about DNSSEC and vastly fewer than that care about DANE so I expect at some point support for both will disappear from both the DNS root servers and all DNS software. You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image downloads anyway, since they have OpenPGP signatures: https://www.debian.org/CD/faq/#verify https://www.debian.org/CD/verify -- bye, pabs https://wiki.debian.org/PaulWise
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-03-25 11:30 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zObsl-25S-3@gated-at.bofh.it> |
| In reply to | #5781 |
Am 25.03.20 um 02:50 schrieb Paul Wise: > On Tue, 2020-03-24 at 15:48 +0100, Elmar Stellnberger wrote: > >> I hope this is gonna happen anytime soon. DANE and thus a valid TLSA >> record is of very high value and importance for getting a genuine >> download of Debian. As I have mentioned before downloads via Tor can be >> spoofed like my last Debian Live 10 download which turned out to be >> infected by debchecheckrooting against the Debian 10 DL-BD. > > TBH, very few people care about DNSSEC and vastly fewer than that care > about DANE so I expect at some point support for both will disappear > from both the DNS root servers and all DNS software. > > You shouldn't be relying on DNSSEC/DANE/TLS to verify Debian image > downloads anyway, since they have OpenPGP signatures: > > https://www.debian.org/CD/faq/#verify > https://www.debian.org/CD/verify > OpenPGP is no solution to the issue. You need to download the public key and this is usually done over insecure https without DANE. Furthermore it is a vibrant issue that the private key can be stolen even if it is stored offline. How does Debian guard its private key? Is the key used to sign Debian CD images put offline? What security measures do apply? DANE is not gonna disappear. There is no DANE support for the www yet but mail servers do increasingly use DANE. Many public hosters support DNSSEC these days and adding a TLSA record is usually little work if you are in the possession of the server infrastructure. Third, as we have a tool to download over DANE/https now (a̅tea) I would suggest that we should make use of it. According to my experience use of DANE is the only way around this security nightmare. It has proven to hold strong and secure in practice. DANE per se will never disappear as it is the decision of the server maintainers whether to provide a TLSA record or not. DNSSEC per se is used more than DANE.
[toc] | [prev] | [next] | [standalone]
| From | Elmar Stellnberger <estellnb@elstel.org> |
|---|---|
| Date | 2020-03-26 11:10 +0100 |
| Subject | Re: debcheckroot v2.0 released |
| Message-ID | <zOxCy-7nF-1@gated-at.bofh.it> |
| In reply to | #5782 |
Am 26.03.20 um 03:50 schrieb Paul Wise: > On Wed, 2020-03-25 at 11:27 +0100, Elmar Stellnberger wrote: > >> OpenPGP is no solution to the issue. >> DANE is not gonna disappear. > > I guess we will have to agree to disagree, end of thread for me. > I am far from not having to say more about it. Most people who provide signatures store their private key on a machine also used for web browsing. I know this also applies to Debian because keeping the key secure or at best offline would require some considerable provisions and AFAIK none of you have implemented a separation of concerns i.e. one computer for browsing and another one for secure ssh connections. That would be required though to keep the secret key safe. We have an arbitrary code execution bug in browsers every few month and that does not count all the zero day exploits at all. Sites in the www are commonly spoofed by secret services. Even the Snowden revelations do tell (operation Quantum insert). That way the secret key is guaranteed to be compromised a few milliseconds after its creation. The NSA also has its own key stealing programme. I wanna tell you that you are better off checking the SHA512SUM. That one, as soon as you have retrieved a genuine one, can no more be spoofed. Besides this it is a common attack vector to infect computers via online updates. Once more they need to know the secret key in order to do so!
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | linux.debian.security
csiph-web