Re: Check for revocation certificates before running apt-get?
Paul Wise: On Mon, Dec 16, 2013 at 1:34 PM, adrelanos wrote: I am wondering how excited the apt developers would be about adding a bash script to their app. I'll see how far I get and contact them when there is something to talk about. I suppose POSIX shell would be preferable. I always hoped there is no holy war sh vs bash and never found any existing discussions. Could you point me to these please if they exist? I for one preferred bash over sh with my, perhaps naive, why bother with sh when you can use its successor that is even an essential package in Debian view. Hopefully implementing this in bash instead of sh isn't a deal breaker? Imagine for a moment, you would like my implementation... Then, would you suppose to activate this by default in Debian? Not sure, but the feature should at least be present even if it is disabled by default... In that case, can the keyservers handle the load from the mass of Debian and its derivatives users? Should we ask keyserver operators or on gnupg mailing list if that is a fine idea? Zero idea, best ask indeed. Asked: https://lists.nongnu.org/archive/html/sks-devel/2013-12/msg00076.html Seems like keyservers should not be used. Unless that extra DNS for automated replies gets implemented - joining keyserver infrastructure forces however is beyond what I wanted to put into this. I guess I will make the code for downloading the revocation certificates configurable and use http/curl. What PPAs you're using isn't a secret anyway, since apt traffic isn't encrypted. If you want to hide which PPAs you're using and which signing keys you're refreshing, I think it's best to route all that traffic over Tor. I don't understand the benefit in selectively routing key fetches of signing keys over Tor while leaving the rest in the clear. That makes sense. Add a system daemon for parcimonie But parcimonie already has a system daemon? AFAICT it only has a per-user daemon. I see. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c52663.3060...@riseup.net
Re: Check for revocation certificates before running apt-get?
Paul Wise: On Sun, Dec 15, 2013 at 11:15 AM, adrelanos wrote: I can try that. Should that become a separate package or part of, well apt-get? It would probably just be three files, a config file, an /etc/apt/apt.conf.d/ config fragment and a bash script. I'm guessing the apt package would be the place to put it. I am wondering how excited the apt developers would be about adding a bash script to their app. I'll see how far I get and contact them when there is something to talk about. My initial thought would be that the implementation when run from the apt hook would go through all the trusted keyrings and fetch the keys from each of them from the default keyservers in GPG. Imagine for a moment, you would like my implementation... Then, would you suppose to activate this by default in Debian? In that case, can the keyservers handle the load from the mass of Debian and its derivatives users? Should we ask keyserver operators or on gnupg mailing list if that is a fine idea? That was the reason for my proposal using http. I forgot to add, that I planed to do that to reduce load from the keyservers. For Whonix I'd like to activate this feature by default. If keyservers are capable and willing to take the load is still unknown. But at least sourceforge does not pose any traffic limitations. When keyservers don't mind, great, will make the implementation simpler. /etc/apt/trusted.gpg /etc/apt/trusted.gpg.d/*.gpg That would probably be fine for most Debian users but at that point I remembered that the Riseup OpenGPG best practices document has something to say about keyring refreshes; that keyring refreshes should happen using parcimonie to make correlation attacks harder. parcimonie hides keys you have in your keyring. Personal contacts. That's worth hiding. If all Debian users were to always automatically check if the official singing key has been revoked, that wouldn't be a secret worth to hide. [Routing that traffic over Tor such as having an .onion apt mirror is a different discussion we had on this list a while ago.] This would especially be a problem for folks with multiple PPAs in their apt trusted keys. What PPAs you're using isn't a secret anyway, since apt traffic isn't encrypted. If you want to hide which PPAs you're using and which signing keys you're refreshing, I think it's best to route all that traffic over Tor. I don't understand the benefit in selectively routing key fetches of signing keys over Tor while leaving the rest in the clear. https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#make-sure-you-are-receiving-regular-key-updates That complicates things but would probably still be doable, thoughts: PPA users are another reason for having a modular /etc/apt-revok.d/ config folder. In future, the add-apt-repository tool or the ppa-package itself could drop a configuration snippet in that folder. parcimonie is great. These tools could complement themselves. But they have different purposes. parcimonie keeps your keyring current by refreshing the keys at random times from the key server [over Tor]. apt-key-revok-check however would check for revoked apt keys every time [or configurable, only once per day or x] right before running apt-get update. Add a system daemon for parcimonie But parcimonie already has a system daemon? that refreshes the apt keyring when tor network is available. I don't know if parcimonie can be configured to refresh the apt keyring. Would probably be worth a feature request. I am not skilled to add such a feature to parcimonie. That feature should however be completely unrelated to what we're discussion here. Add an apt hook that refreshes trusted.gpg keyrings in /etc have not been touched recently (so it works when parcimonie or another refresh mechanism is not being run) and also checks all keyrings for revoked keys and I don't think I can integrate with parcimonie, since I don't speak perl. reports them to the user. I can write a nice cli app safely doing the key fetching before running apt-get. And also maybe also add hooks for certain events aka revocation certificate found. So other root users can drop configuration snippets to /etc/apt-revok.d/ and define scripts which get run upon certain events. One may add a mail notification, someone else can add zenity popup or else. Even without notification. Should a revocation certificate get imported, apt-get will tell them, that the apt signing key is no longer valid anyway. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ae90d0.2010...@riseup.net
Re: Check for revocation certificates before running apt-get?
Paul Wise: On Sat, Dec 14, 2013 at 6:47 AM, adrelanos wrote: is it possible to hook apt-get somehow to do some action done before apt-get starts any network activity? Based on a quick grep of the apt package, APT::Update::Pre-Invoke might be what you want. That seems perfect. Here is an extremely dangerous example of how it can be used: http://www.webupd8.org/2009/06/automatically-import-launchpad-ppa-keys.html It would be possible to do it in a secure way but that example is definitely not secure. I agree it's not secure. Ubuntu PPA's do teach users download keys without any verification. That is worrying but another story. I would like to add refresh gpg keys from a server first to check if any of them have been revoked in meanwhile. That sounds like a useful feature to have. Thanks. When you implement this, please ensure it isn't vulnerable to any duplicate-keyid problems: http://debian-administration.org/users/dkg/weblog/105 Damn, I wasn't aware of the latest news that long key ids are now also insecure. Thank you for educating me. (I am asking this because I would like to add such a feature to Whonix, which is a derivative of Debian. Hope you don't mind me asking here.) I would encourage you to get that (or a background cron job) into Debian instead, it is a pretty important security enhancement IMO. I can try that. Should that become a separate package or part of, well apt-get? It would probably just be three files, a config file, an /etc/apt/apt.conf.d/ config fragment and a bash script. I would implement it as a bash script (since I am not capable of any other language). How to name it? apt-key-revocation-check? I am happy about better suggestions. The bash script would source the configuration folder /etc/apt-revok.d/ for bash configuration fragments in lexical order. That way Debian could ship their config /etc/apt-revok.d/20_debian and derivatives could just drop in their extra config on top of that. The config file would contain one or multiple links on http servers. Download would happen over http. Example, /etc/apt-revok.d/30_whonix could contain: aptrevok_linklist+= http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file apt_revok_key_folders+= /usr/share/whonix/keys/whonix-keys.d apt-key-revocation-check would then download http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file and http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/aptrevok/revocation-file.asc. Import all keys stored inside the /usr/share/whonix/keys/whonix-keys.d folder into a temporary gpg directory and check if revocation-file can be verified. If yes, import it into apt-key. I could even add config options what should happen if no remote page can be reached or add hooks for pre-fetch, post-fetch, found-revok certificate, found-no-revok certificate etc. And if you're not sure if it's worth to mentor me on this, you can check out some of my related work. [1] [2] [3] Cheers, adrelanos [1] https://github.com/Whonix/Whonix [2] https://github.com/Whonix/Whonix/blob/master/whonix_shared/usr/bin/whonix_repository [3] https://github.com/Whonix/Whonix/blob/master/man/whonix_shared/whonix_repository.8.ronn -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ad1eb7.6060...@riseup.net
Check for revocation certificates before running apt-get?
Hi, is it possible to hook apt-get somehow to do some action done before apt-get starts any network activity? I would like to add refresh gpg keys from a server first to check if any of them have been revoked in meanwhile. There are hooks for dpkg (DPkg::Pre-Invoke, DPkg::Post-Invoke), but not really for apt-get? Closest thing for now seems to use dpkg-divert and a wrapper? Do you have any better solution in mind? (I am asking this because I would like to add such a feature to Whonix, which is a derivative of Debian. Hope you don't mind me asking here.) Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ab8e6c.2050...@riseup.net
Re: End-user laptop firewall available?
Bastian Blank: On Sat, Dec 07, 2013 at 10:55:30AM -0600, Richard Owlett wrote: Any help/direction appreciated. The answer is: None. If you don't have anything listen on the network, nothing can be accessed anyway. Does Debian still come with open ports in a default installation? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a46fc5.4010...@riseup.net
Re: End-user laptop firewall available?
Frédéric CORNU: Le 08/12/2013 11:34, Bastian Blank a écrit : On Sat, Dec 07, 2013 at 10:55:30AM -0600, Richard Owlett wrote: Any help/direction appreciated. The answer is: None. If you don't have anything listen on the network, nothing can be accessed anyway. Bastian What about the possibility of a malicious piece of software beeing installed and starting listening to incomming connections without the knownledge of the system user ? Malicious software as in trojan horses, botnet clients? In that case, not sure that were to help. Do they still need open incoming ports nowadays? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a4706e.4030...@riseup.net
How (un)safe would Debian be when only using the security.debian.org repository?
Hi! How (un)safe would it be...? When using Debian while... Not using: deb http://ftp.us.debian.org/debian stable main contrib non-free deb http://security.debian.org stable/updates main contrib non-free Only using: deb http://security.debian.org stable/updates main contrib non-free Does that change when using testing instead of stable? I.e... Not using: deb http://ftp.us.debian.org/debian testing main contrib non-free deb http://security.debian.org testing/updates main contrib non-free Only using: deb http://security.debian.org testing/updates main contrib non-free Or the same question in other words: are sometimes updates fixing security issues released though repositories other than the security repository? Why would someone interested in doing that? Getting fewer updates, saving bandwidth, time and system load. Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527fe374.3090...@riseup.net
Re: Debian APT Key Revocation Procedure
Paul Wise: On Thu, Oct 31, 2013 at 8:55 PM, adrelanos wrote: What are your plans if you ever have reason to believe that the Debian archive signing key has been compromised? It is unlikely that the people responsible for that are reading this list. I suggest you contact them (DSA, ftpteam) directly. The DSA told me it doesn't relate to DSA and the ftpteam didn't reply. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527d6377.30...@riseup.net
Re: Debian APT Key Revocation Procedure
Paul Wise: On Thu, Oct 31, 2013 at 8:55 PM, adrelanos wrote: What are your plans if you ever have reason to believe that the Debian archive signing key has been compromised? It is unlikely that the people responsible for that are reading this list. I suggest you contact them (DSA, ftpteam) directly. Is there a public mailing list? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5273aa1b.5080...@riseup.net
Re: Debian APT Key Revocation Procedure
Paul Wise: On Thu, Oct 31, 2013 at 8:55 PM, adrelanos wrote: What are your plans if you ever have reason to believe that the Debian archive signing key has been compromised? It is unlikely that the people responsible for that are reading this list. I suggest you contact them (DSA, ftpteam) directly. Thank you, Paul. I mailed DSA. I find it a non-ideal, that there is no place to discuss this in public. (Neither DSA nor ftpmaster mailing list is publicly archived or allows public sign up.) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5273dcd2.1070...@riseup.net
Debian APT Key Revocation Procedure
What are your plans if you ever have reason to believe that the Debian archive signing key has been compromised? http://ftp-master.debian.org/keys.html says: Key Revocation Procedure A revokation certificate for the archive key is produced at the time of the creation of an archive key. The program gfshare (package libgfshare-bin) (a Shamir's secret sharing scheme implementation) is then used to produce 12 shares of which 7 are needed to recover the revokation cert. This procedure is for use in emergencies only (such as losing ftp-master.debian.org and all of the backups, a hopefully unlikely event) as the key can normally be used to produce its own revokation certificate. But what could you do with the revocation certificate? Only manually spread the news and ask users to obtain the revocation certificate? Or will the apt on Debian user's machines somehow learn about that revocation certificate? If so, how does that procedure work? Where is it configured? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52725325.7030...@riseup.net
Re: SSL for debian.org/security?
For apt-get a self-signed certificate could be used which comes together with Debian. No CA required. This is both simpler and safer. Vipul Agarwal: How about if we use a SSL certificate signed by debian's own root CA which can be shipped with the distros? This will eliminate the paranoia about NSA having control over the existing CA especially the one based in the States. -Vipul On Oct 29, 2013 4:18 AM, Volker Birk v...@pibit.ch wrote: On Mon, Oct 28, 2013 at 09:31:35PM -0400, Mark Haase wrote: It's a bit ironic that the Debian security site doesn't offer SSL, right? If an attacker can MITM an organization that uses Debian, then they can MITM the Debian security page and control what security bulletins that organization can access. BTW: if the NSA take one single trusted CA (and they did for sure), HTTPS is b0rken for each site. Yours, VB. -- Volker Birk Oberer Graben 4, 8400 Winterthur, Schweiz mailto:v...@dingens.org http://fdik.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5270d88b.5010...@riseup.net
Re: SSL for debian.org/security?
Celejar: Maybe I'm missing something, but the security of the apt system has nothing to do with SSL - it uses GPG signatures. This discussion about SSL concerns the website, etc. That was indeed the original question, but it then drifted into the direction into how great is would be to further protect apt-get using SSL and/or Tor hidden services. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5270f95f.1000...@riseup.net
Re: SSL for debian.org/security?
Djones Boni: On 30-10-2013 11:05, Celejar wrote: You're snipping crucial context; my comment above was in response to this: For apt-get a self-signed certificate could be used which comes together with Debian. No CA required. This is both simpler and safer. I was pointing out that this comment makes no sense in the context of apt-get. It sounds like you're referring to the website or email system. I am talking about updates. Yes. Apt uses OpenPGP to verify the integrity and authenticity of the packages it downloads. But how does apt get these packages? Over insecure HTTP. Hacking DNS or MITM attack can hide updates from you or a country. Then you are vulnerable due out-of-date software and you don't even know about it. I think we can refer to the TUF threat model [1] when talking about attacks against package managers. [1] You may have a rollback attacks and/or indefinite freeze attacks in mind. Perhaps others. Tell us. Debian protects against these to some degree, because it uses the valid-until [2] field, which is great. Package lists are valid for two weeks, though. Getting package lists over SSL and/or Tor hidden services could make this even more secure. [1] https://www.updateframework.com/projects/project/wiki/Docs/Security [2] http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52710cc3.5040...@riseup.net
Re: SSL for debian.org/security?
Jordon Bedwell: On Tue, Oct 29, 2013 at 4:29 AM, Nikolay Kubarelov n...@tightwax.com wrote: I would use Tor hidden service instead of SSL. Wait: What? Can't tell if serious. Why shouldn't that be serious? Tor hidden services can not only be used to hide the location of a server, but they also provide alternative end-to-end encryption, independent from SSL CA's. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526f8881.2070...@riseup.net
Re: SSL for debian.org/security?
Tormen: On 29/10/13 10:44, Jordon Bedwell wrote: On Tue, Oct 29, 2013 at 4:29 AM, Nikolay Kubarelov n...@tightwax.com wrote: I would use Tor hidden service instead of SSL. Wait: What? Can't tell if serious. And then again: http://yro.slashdot.org/story/13/08/04/2054208/half-of-tor-sites-compromised-including-tormail ^^ That is a totally unrelated story. No argument against hidden services at all. - They took down a hidden service host violating laws - not of concern for Debian, since not violating laws. - They didn't break Tor hidden services, they broke the server software of someone who allowed anyone to run arbitrary php scripts. - Only one hidden service which provides free hidden hosting to others was taken down. Anyone hosting it's own hidden service was unaffected. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526f8887.9040...@riseup.net
Re: SSL for debian.org/security?
Djones Boni: A Debian THS is a good idea for the security it provides, not for anonymity or down rate. It would be harder to someone MITM and hide updates from you. That is why Debian should use SSL (and THS). Downloading apt-get updates over Tor hidden services would be awesome! - Even when an adversary found a way to exploit apt-get's OpenPGP verification, the exploit could not be used, because Tor hidden services implement its own encryption/authentication. - An adversary could not even know that someone is downloading apt-get updates. - We obscure more internet traffic, good for Tor (diversifying user base and use cases), adding more hay to the haystack. - It becomes more difficult to mount rollback/freeze attacks. We have the valid-until field, but Tor HS would be a nice as defense in depth. And before someone says, the Tor network does not want such kind of traffic... Having my Whonix (a Debian derivative) hat on: There is no such issue. One can use Tor to download updates. We asked torproject.org, if it is okay to download operating system updates over Tor, see [1] [2]. Andrew Lewman (Executive Director, Director, press contact [3]) does also download a lot of updates over Tor and did not complain. [4] [1] https://lists.torproject.org/pipermail/tor-talk/2012-March/023486.html [2] https://lists.torproject.org/pipermail/tor-talk/2012-March/subject.html#23507 [3] https://www.torproject.org/about/corepeople.html.en [4] https://lists.torproject.org/pipermail/tor-talk/2012-March/023493.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526fa1a2.5080...@riseup.net
Re: SSL for debian.org/security?
Djones Boni: A better idea is offer both SSL and a Tor Hidden Service. You choose which use. Yes, having both is better. Only relying on Tor Hidden Services wouldn't be a good idea. Offering as an option would be awesome! Do not forget Tor encryption is not considered secure anymore. There are of course a lot opportunities in Tor and Hidden Services for improvements, but please consider, that there are no reports that either Tor or Hidden Services were ever successfully deanonymized.* The latest information we got is still We will never be able to de-anonymize all Tor users all the time [1] - so it's worth going for it. [1] http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document * detective work and/or exploiting the server or client software behind Tor is another story -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526fa1a8.6040...@riseup.net
Re: Script to System Check Integrity against Debian Package Repository
Paul Wise: On Wed, Sep 18, 2013 at 9:36 AM, Török Edwin wrote: Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? That is a slightly short-sighted way to do it; if you restore from scratch without doing any forensics you won't know which methods your attackers used and how you can defend yourself from them after you have restored the system from scratch. Perhaps they will attack you again soon afterwards. I didn't have that argument in mind, but I am happy to read it. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5239bd83.7050...@riseup.net
Re: Script to System Check Integrity against Debian Package Repository
Török Edwin: On 09/17/2013 09:45 PM, adrelanos wrote: Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine. Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) It is copied from /usr/lib/grub/i386-pc: $ dpkg -L grub-pc-bin | grep video_fb /usr/lib/grub/i386-pc/video_fb.mod Thanks for the technical information. That will help to audit those. - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? Aren't they generated by the package's postinst script? Probably yes, but it the postinst script calls something like update-mime-database, I am not sure how to compare it's outputs. I must check first if it's outputs are deterministic (when using the same versions, of course). Maybe I have to run such commands on the trusted system to generate those files and then compare with the untrusted system. Sounds like quite some package specific work. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5239fe22.5000...@riseup.net
Script to System Check Integrity against Debian Package Repository
Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine. * You have a Debian Live CD or USB install, which you believe to be clean. * You want to boot from the trusted system (CD or USB) and check the internal hdd, which might be compromised. Non-solutions: * debsums: is a fine tool, yes. But its own man page acknowledges, that it has limited use as a security tool. It also only supports checking the system in which itself it is running. There is no feature to check a Debian, which is in another folder. * I have looked into intrusion detection systems (debsums,) Afick, AIDE, FCheck, Integrit, Osiris, OSSEC, Samhain, Tripwire, but they all have in common, that they want to create a known-good database before auditing. This doesn't scale very well, because updates are pretty frequent, which render that known-good database less useful. Re-creating the known-good database after updating isn't very safe either - let's say apt-get had a bug and installed a malicious package, then the checksum of that malicious package would end up in the known-good database. Goals: * No code within the untrusted system must be required to be executed in order for the check, since no code inside the vm image is trusted while testing. Work in progress: I wrote a bash script, which uses dpkg from the trusted system, to parse the /var/lib/dpkg/status file from the untrusted system. It then uses the trusted system, to download all packages, which are claimed to be installed in /var/lib/dpkg/status and extracts them. The sha512 (could be easily replaced with sha256) checksum of all files which come with the package is created on the trusted system and checked against the files from other untrusted system. Known good files will be stored in an array, mismatches will be reported and stored in array as well. Symlinks are checked as well. At the end, the script goes through all files within the untrusted system and compares which one are already known as good or bad and reports which extra files, which have not been verified against anything, are there. Ideally, there are very few extra files. Only changed configuration files and files manually created by the user. In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? And I have open questions, such as: - Which package is responsible for creating device files (/dev/...)? How to check if they are legit? - Is there a signed dump of the grub boot sector somewhere? - What other places exist to hide rootkits? Where would be a good place to ask such questions? All in all, I am wondering, is writing such a verification script a promising or futile approach? At the moment, the script is still Whonix specific and verifies a .img image file. It wouldn't be hard to make the folder it audits configurable and to check any other hdds or root folders. If you like to have a look at the work in progress script, see: https://github.com/Whonix/Whonix/blob/master/release/verify_build Comments, criticism, enhancements, etc. welcome. It would be great if anyone is interested to co-author the script (we can pick any Free license) to make it usable for the general use-case. Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5238a34e.6040...@riseup.net
How secure is an installation with with no non-free packages?
How secure is a Debian installation packages installed only from main, none from contrib or non-free? It will lack for example the firmware-linux-nonfree package and the intel-microcode / amd-microcode package. At least the microcode one is security relevant? Are there any other packages which might be important to have installed for security reasons? I mean, how secure is it in comparison with those packages installed vs not having them installed? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523234f5.1090...@riseup.net
Re: How secure is an installation with with no non-free packages?
adrelanos: How secure is a Debian installation packages installed only from main, none from contrib or non-free? It will lack for example the firmware-linux-nonfree package and the intel-microcode / amd-microcode package. At least the microcode one is security relevant? Are there any other packages which might be important to have installed for security reasons? I mean, how secure is it in comparison with those packages installed vs not having them installed? I apologize, I didn't want to start a discussion of Open Source vs closed source. (Feel free to have it, I am delighted to read your thoughts on it, but I'd be also happy about an answer to the question I meant to ask but failed to properly state.) Sorry for not asking clear in the first place. To rephrase my original question: How vulnerable is Debian installation without intel-microcode / amd-microcode package? Are there other contrib and/or non-free packages, similar to the microcode package, which make the system vulnerable, if not installed? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52325160.1000...@riseup.net
Re: How secure is an installation with with no non-free packages?
Jose Luis Rivas: So no, there's no other contrib/non-free packages there. I didn't want to imply, that there are preinstalled. The reason why you can't install Debian directly from a WiFi with some manufacturers is precisely that we do not ship non-free nor contrib software by default in our Debian installation different to what does other distributions like Ubuntu (no offense meant). And this is fine and I don't want to go into that political vs convenience discussion either. So we have the (intel/amd)-microcode and the firmware-linux-nonfree package which should be installed to improve security? Are there any other packages of this type? What would you do if there was an exploit in the wild, which uses an vulnerability in (intel/amd)? Let's say any website could prepare some html code which would trigger a remote code execution. One that can only be fixed by having the (intel/amd)-microcode package installed. Is this a possible scenario? What would you (Debian) do in this case? (I am not suggesting anything here, I am just interested in those questions.) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52326419.2070...@riseup.net
Re: How secure is an installation with with no non-free packages?
Okay, thank you for your reply! Convinces me. Joel Rees: I assume you have read his essay on trusting trust? Yes, but I am not claiming, that I fully understand it. rant-mode Not perceived as rant at all. Are there other contrib and/or non-free packages, similar to the microcode package, which make the system vulnerable, if not installed? Depends on what you're using the system for. I was just asking generally and I think we have already identified three packages of that type. Wish I could say more, but we are really just barely beginning to scratch the surface of building a stable computer technology. Yes, the more I dig into one topic, the open questions remain and them stronger the conclusion we're totally screwed becomes. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52326643.3000...@riseup.net
Re: How secure is an installation with with no non-free packages?
Joel Rees: I am not Debian, but I am in rant-mode on this subject today, so bear with me -- On Fri, Sep 13, 2013 at 10:02 AM, adrelanos adrela...@riseup.net wrote: Jose Luis Rivas: So no, there's no other contrib/non-free packages there. I didn't want to imply, that there are preinstalled. The reason why you can't install Debian directly from a WiFi with some manufacturers is precisely that we do not ship non-free nor contrib software by default in our Debian installation different to what does other distributions like Ubuntu (no offense meant). And this is fine and I don't want to go into that political vs convenience discussion either. You can't avoid it now. (Thanks to NSA and Intel deciding to boogie together. Let the children boogie.) So we have the (intel/amd)-microcode and the firmware-linux-nonfree package which should be installed to improve security? Are there any other packages of this type? We'd like to say they are unique. They are unique in that they are the CPU, but any binary blob required by the hardware you are using is going to have the same set of problems, and most of them, even when we move the drivers out of the kernel, are going to have the capability of subverting the whole box. We'd like to say that it's all Intel's fault for pushing the market so far so fast, but we can only say they have been a major contributor to the problem. (We have, also, each one of us.) What would you do if there was an exploit in the wild, which uses an vulnerability in (intel/amd)? Do you mean, in the cpu itself, or in the microcode? Microcode. (I guess if the vulnerability can not be fixed with some kind of firmware upgrade and is used in the wild, that would be a reason to get it replaced for free or being required to buy a new one.) Let's say any website could prepare some html code which would trigger a remote code execution. Ergo, on vulnerable CPU/microcode combinations. One that can only be fixed by having the (intel/amd)-microcode package installed. So you're thinking the CPU, but which level of microcode? No idea. Is this a possible scenario? Of course. Especially now that the bad guys have tools that allow them to build targeted tools fairly easily. What would you (Debian) do in this case? Do you mean, I don't try to mean anything in this thread. :) Just asking questions. would Debian fold up and go away if the only way to provide a secure OS were to be to include certain non-free packages by default? And no, I think discontinuing Debian for such reasons is extremely unlikely and many actions seem to be much more likely - I may not be able to guess what you are going to do, hence I am asking. They already do (as Jose Luis Riva indicated). It just requires a certain amount of action on your part so that they can limit the amount of non-free stuff you have to load. At the very least, AMD machines do not need Intel microcode, and vice-versa. Yes, that is very nice. That's why it's important to have more than one major CPU vendor, Sure, I am not against having 10 or more per country either. I believe monopolies are almost always bad. even if Intel's bragging that they have beaten everyone else on all technical fronts had any merits whatsoever. (It doesn't. They haven't even come close. Their current excesses are catching up to them now.) (I am not suggesting anything here, I am just interested in those questions.) And I suppose I am not contributing anything meaningful to the conversation. Happy to read your thoughts. Sorry, but this is a pet peeve of mine. Understandably. It's a terrible pity. None of that is the fault of Debian, you're doing fine providing a Free operating system and I am not asking you to fix the rest of the world as well. Good to be aware of it, however. We can't afford the results when microprocessors become this complex, and one of the reasons I hate Intel is that they have pushed the complexity so hard to maintain their market advantage, and it just makes a mess of the industry. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52327254.7030...@riseup.net
Re: Compromising Debian Repositories
Timo Juhani Lindfors: adrelanos adrela...@riseup.net writes: Some Debian maintainers are working on deterministic builds, although they call it reproducible builds, that's great! Link: https://wiki.debian.org/ReproducibleBuilds Terminology is hard :) As mentioned in the bof we can make sure that the build is deterministic or we can record sources of randomness (gettimeofday calls etc.) and then replay then in subsequent builds. Would that still qualify as deterministic for you? I am not nitpicking on the term. :) Any is fine. However you call it, I am very excited about the fact, that there are people interested in it. The end result would be the same? No security advantage/disadvantage for one or another method? The latter method might pay off later and ease porting more packages? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521617e7.40...@riseup.net
Re: Compromising Debian Repositories
Just wanted to share news on this topic. Why are deterministic builds important? Mike Perry from The Tor Project wrote a blog post: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise Some Debian maintainers are working on deterministic builds, although they call it reproducible builds, that's great! Link: https://wiki.debian.org/ReproducibleBuilds (The later is not really news, but I wonder that no one posted this link and I wasn't aware of it either.) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52150286.1000...@riseup.net
Re: Compromising Debian Repositories
intrigeri: Hi, adrelanos wrote (04 Aug 2013 03:04:33 GMT) : Volker Birk: On Sat, Aug 03, 2013 at 10:38:34AM +, adrelanos wrote: Volker Birk: On Sat, Aug 03, 2013 at 09:16:40AM +, adrelanos wrote: That should help to defeat any kind of sophisticated backdoor on build machines. Really? How do you detect, if maintainer's patches contain backdoors? Someone else builds the same package (binary) and detects a different checksum. - That required deterministic builds. There will be the correct checksum, if the maintainer of the package does it. Why? So no way to detect that with deterministic builds. Why not? I believe you have missed something around if maintainer's patches contain backdoors. Maintainer's patches are part of the source package, and applied to the source before the binary package is built. As you can see, it's obvious checksums and deterministic builds don't help in such a case. Sure, if you refer to the trusting trust issue, this deterministic builds don't tackle this. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fe3a21.5090...@riseup.net
Re: Compromising Debian Repositories
Heimo Stranner: On 2013-08-04 09:50, intrigeri wrote: Hi, adrelanos wrote (04 Aug 2013 03:04:33 GMT) : Volker Birk: On Sat, Aug 03, 2013 at 10:38:34AM +, adrelanos wrote: Volker Birk: On Sat, Aug 03, 2013 at 09:16:40AM +, adrelanos wrote: That should help to defeat any kind of sophisticated backdoor on build machines. Really? How do you detect, if maintainer's patches contain backdoors? Someone else builds the same package (binary) and detects a different checksum. - That required deterministic builds. There will be the correct checksum, if the maintainer of the package does it. Why? So no way to detect that with deterministic builds. Why not? I believe you have missed something around if maintainer's patches contain backdoors. Maintainer's patches are part of the source package, and applied to the source before the binary package is built. As you can see, it's obvious checksums and deterministic builds don't help in such a case. Cheers, I think the real issue is about if the malicious patch is not part of the source package. Then nobody could find that patch by reading the source code. Patches no in the source package is what deterministic builds could detect. I think he refers to patches that look good, but contain sophisticated internally added vulnerabilities (trusting trust). -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fe3aa1.4020...@riseup.net
Re: Compromising Debian Repositories
Volker Birk: On Sun, Aug 04, 2013 at 03:04:33AM +, adrelanos wrote: Volker Birk: On Sat, Aug 03, 2013 at 10:38:34AM +, adrelanos wrote: There will be the correct checksum, if the maintainer of the package does it. Why? How and by whom are checksums defined? Please have a look into the BitCoin (official, qt) build process. Multiple builders build the same binary and when they run a $hashsum tool on individual resulting binary files, they will always have the same hash sum. Same goes for the archive files. Those builders publish their results. Anyone else can download their source code, read their build instructions, build from source code and get end up with the same hash sums. Compare that with what they offer for download. If something mismatches, there is something wrong. And if you're taking the build machine, you can inject “correct” checksums, too. But that will get caught when someone else builds the package and comes up with a different checksum? Or do you talk about hash collisions? No, I'm talking about the process by whom and when a checksum is defined. Checksums should be created on the .deb and the individual files. The advantage of deterministic builds would be, that these checksums would always be the same, no matter when and by whom the build is made as long as the source code isn't changed. Whoever is able to define checksums is able to circumvent each security measure basing on such checksums. Thats up the community to come up with a general policy on how that should be done. To “define” does not mean she/he has to know a secret to apply the checksum. Yes, no secrets. I's enough that she/he is authorized to use the communication channel where data is injected, for which then a checksum is computed. Yes the server could claim a different checksum. But anyone downloading the source package and building it would get a different checksum. Sure, deterministic builds are only the first step. Getting up a system to automatically to track changes in source code and to compare hash sums would be required as well. I am afraid if deterministic builds can't solve all problems at once. Do you see no advantages at all? I am just interested to have in a couple of years still operating systems without any secretly built-in trojans because build servers got compromised with zero days. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fe4464.4060...@riseup.net
Re: Compromising Debian Repositories
Michael Stone: On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: I think the real issue is about if the malicious patch is not part of the source package Why? It certainly makes your argument simpler if you arbitrarily restrict the problem set, but it isn't obvious that it makes sense. If I was going to backdoor something, I'd just make an innocent-looking coding error that would enable a successful exploit; I certainly wouldn't put in a commented section of code that says backdoor here. With sufficient effort it wouldn't be hard to inject such a vulnerability that would go unnoticed for years--and I'm not sure why that's less of an issue than someone making a one-time build with a malicious patch that is not part of the source package. An innocent-looking coding error requires a malicious maintainer. A malicious patch not part of the source code can be done by any adversary who compromised the build server. I think the latter is more simple, risk free and anonymous. Getting rid of possibilities for intentional innocent-looking coding error is possible as well. First of all, how much security is the goal vs required effort? Is pragmatic security, as in no random script kiddy can take down any Debian powered systems sufficient or is it we don't want all the three letter agencies around the globe being always able to remotely access any Debian system. As far I know, only lower level programming languages such as assembler, C and C++ open up for sophisticated intentional innocent-looking coding errors, right? Bugs possibly leading to remote code execution are much more obvious to spot in higher level languages such as python? If that case and more than pragmatic security is the goal, the use of lower level languages should be restricted to cases where other solutions aren't possible (bootloader etc.). And frozen. So that the code is 100% stable and vulnerability free after some time. It should be possible in theory if our machines get more performance over time? I think that would be quite painful to rewrite so many tools. Are there any better solutions to the trusting trust issue? Or will the fight against backdoors be lost at some point? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fec610.1080...@riseup.net
Re: Compromising Debian Repositories
Daniel Sousa: On Sun, Aug 4, 2013 at 2:55 PM, Michael Stone mst...@debian.org wrote: On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: I think the real issue is about if the malicious patch is not part of the source package Why? It certainly makes your argument simpler if you arbitrarily restrict the problem set, but it isn't obvious that it makes sense. If I was going to backdoor something, I'd just make an innocent-looking coding error that would enable a successful exploit; I certainly wouldn't put in a commented section of code that says backdoor here. With sufficient effort it wouldn't be hard to inject such a vulnerability that would go unnoticed for years--and I'm not sure why that's less of an issue than someone making a one-time build with a malicious patch that is not part of the source package. First of all, they could apply that change (calling it a patch was not one of my greatest ideas) for every update they do, it's not necesserily a one time thing. It's also much easier (and probably much dangerous) to write some code that doesn't need to be cryptic, you can just write whatever you want instead of trying to find something that can pass as a mistake (although this seams a fun thing to do) Despite this, the most important reason is that I don't see anyway to prevent that from happening, but we can prevent this. It's not easy and will take a lot of work, but at least it is theoretically possible. Defeating the the intentional non-obvious bug leading to vulnerability thing? How to defeat it in theory? Please elaborate. I don't have any experience on this and I would not know where to start (I haven't even done a Debain package, ever), but if there's any workgroup or anyone working on this, I would like to help -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fec685.3020...@riseup.net
Re: Compromising Debian Repositories
I think deterministic builds would be the best answer to ensure in long term being free of backdoors. A deterministic build process to allows multiple builders to create identical binaries. This allows multiple parties to sign the resulting binaries, guaranteeing that the binaries and tool chain were not tampered with and that the same source was used. It removes the build and distribution process as a single point of failure. [1] That should help to defeat any kind of sophisticated backdoor on build machines. [1] Credit for most of this post goes to http://gitian.org/. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fcca78.5080...@riseup.net
Re: Compromising Debian Repositories
Volker Birk: On Sat, Aug 03, 2013 at 09:16:40AM +, adrelanos wrote: That should help to defeat any kind of sophisticated backdoor on build machines. Really? How do you detect, if maintainer's patches contain backdoors? Someone else builds the same package (binary) and detects a different checksum. - That required deterministic builds. If I would want to attack Debian, I would try to become the maintainer of one of the most harmless, most used packages. And believe me, you wouldn't see at the first glance, that this source code patch is containing a backdoor. I think, it's easy to do this at least while backporting security fixes – but not only. And, additionally: there is plausible deniability of doing so intentionally. I'll agreed. But I am more concerned about things you don't know, zero days, rootkits injecting themselves while building. We're all making mistakes, don't we? Sure. And we're all remembering the issue with key generation, I assume. Attacks on the build process don't seem to be the hugest threats. Why not? Lets make up an example. And attacker only need to compromise the machine which builds the Apache server, doing so with a zero day the attacker bought, lets say thats 10.000 $ or 100.000 $ - within budget of three letter agencies and other criminals. An investment. A compromised Apache who's SSL traffic has an added weakness by the backdoor is most profitable for economic espionage. Not to mention the build tool chains. Thats probably a separate issue. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fcddaa.3080...@riseup.net
Re: Compromising Debian Repositories
Volker Birk: On Sat, Aug 03, 2013 at 10:38:34AM +, adrelanos wrote: Volker Birk: On Sat, Aug 03, 2013 at 09:16:40AM +, adrelanos wrote: That should help to defeat any kind of sophisticated backdoor on build machines. Really? How do you detect, if maintainer's patches contain backdoors? Someone else builds the same package (binary) and detects a different checksum. - That required deterministic builds. There will be the correct checksum, if the maintainer of the package does it. Why? So no way to detect that with deterministic builds. Why not? And if you're taking the build machine, you can inject “correct” checksums, too. But that will get caught when someone else builds the package and comes up with a different checksum? Or do you talk about hash collisions? (Just saw, that you are discussing to move to safer hash algorithms, thats fine and also a separate issue.) Attacks on the build process don't seem to be the hugest threats. Why not? Lets make up an example. And attacker only need to compromise the machine which builds the Apache server, doing so with a zero day the attacker bought, lets say thats 10.000 $ or 100.000 $ - within budget of three letter agencies and other criminals. An investment. A compromised Apache who's SSL traffic has an added weakness by the backdoor is most profitable for economic espionage. Yes, that's possible. But if I would be the intelligence service, I'd better pay one of the maintainers. Job done. Not to mention the build tool chains. Thats probably a separate issue. Yes, and not a small one (it's a classic). If I would have the job at the NSA, I for sure would invest a huge amount of effort to take GCC and LLVM. What an impact! Sure. In my opinion you can only tackle on issue at a time. Of course, having the big picture in mind and coming up with a better idea to kill to birds with one stone is even better. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fdc4c1.7050...@riseup.net
Re: Compromising Debian Repositories
Robert Tomsick: On 08/03/13 13:36, Rick Moen wrote: Quoting Volker Birk (v...@pibit.ch): Really? How do you detect, if maintainer's patches contain backdoors? If I would want to attack Debian, I would try to become the maintainer of one of the most harmless, most used packages. And believe me, you wouldn't see at the first glance, that this source code patch is containing a backdoor Indeed, this whole line of query (from someone who cannot even bother to read debian-legal and wants to be CCed; no thanks) is basically pretty dumb and can be avoided by reading Ken Thompsen's 'Reflections on Trusting Trust', contemplating the nature of the accountability and tracking facilitated by the Debian maintainer process (and its design limits), and, y'know, bothering to think a bit. I'm not sure that hostility is warranted. It still sparked a discussion, and it's definitely interesting to think about. Yes, I also think the original poster should sign up until this discussion as ended. Wasn't the most friendly act someone ever made. He could have just read the mailing list archive. Anyhow... I am happy the topic came up and its being discussed, no matter who started it. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fdc54a.3050...@riseup.net
Integrity check against package repository?
Hi! When there are security updates, I review and install them as soon as possible and think about using automatic updates. From time to time I want to boot from a clean boot CD and check if the system has been compromised. For that reason, I want to check if any packages / binaries have been modified, check the bootloader, check for rootkits. Let's suppose I booted from a clean boot CD and mounted the hdd filesystem. How can I get list of all sha256 hash sums of all installed binaries and configuration files and check them against the versions from Debian repository? I have looked into intrusion detection systems (debsums,) Afick, AIDE, FCheck, Integrit, Osiris, OSSEC, Samhain, Tripwire, but they all have in common, that they want to create a known-good database before auditing. This doesn't scale very well, because updates are pretty frequent, which render that known-good database less useful. Re-creating the known-good database after updating isn't very safe either - let's say apt-get had a bug and installed a malicious package, then the checksum of that malicious package would end up in the known-good database. I think the real solution is checking against the distribution's package repository. How can I do that? Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517f1e87.30...@riseup.net
gpg signatures for Wheezy images
Hi! Stable, http://cdimage.debian.org/debian-cd/6.0.6/i386/iso-dvd/ contains gpg signatures. Wheezy, http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-dvd/ does not contain gpg signatures. Can you offer gpg signatures for Wheezy as well please? Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51278940.7060...@riseup.net
flashplugin-nonfree get-upstream-version.pl security concern
Hi, I do not want to discuss security implications of the upstream closed source Adobe Flash plugin. This is about how the Flash plugin is downloaded and installed in Debian. /usr/sbin/update-flashplugin-nonfree downloads get-upstream-version.pl http://people.debian.org/~bartm/flashplugin-nonfree/get-upstream-version.pl.gz.pgp stores it in /tmp/xxx, runs it and deletes /tmp/xxx. Since get-upstream-version.pl runs as root it can do anything. I don't accuse him personally for anything. But should he ever be compromised (forced, evil maid, etc...) it's very easy to mount a stealth attack. Also reviewing get-upstream-version.pl is cumbersome, you either have to be fast enough to catch it in /tmp/xxx or to download and decrypt it manually using his gpg key. So far it looks clean. But that's not best security practice? What is Debian policy on code execution from user websites? Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c8c45f.1050...@riseup.net
Re: flashplugin-nonfree get-upstream-version.pl security concern
Moritz Mühlenhoff: On Wed, Dec 12, 2012 at 05:52:31PM +, adrelanos wrote: Hi, I do not want to discuss security implications of the upstream closed source Adobe Flash plugin. This is about how the Flash plugin is downloaded and installed in Debian. /usr/sbin/update-flashplugin-nonfree downloads get-upstream-version.pl http://people.debian.org/~bartm/flashplugin-nonfree/get-upstream-version.pl.gz.pgp stores it in /tmp/xxx, runs it and deletes /tmp/xxx. It should at least use a non-predictable tempfile (using tempfile(1) ) Please file bug for that. It's non-predictable. Sorry, I didn't mention it doesn't use /tmp/xxx. xxx was supposed to be a variable, i.e. always changing. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c8cabb.4040...@riseup.net
