Re: concrete steps for improving apt downloading security and privacy
2014/07/07 11:32 Lou RUPPERT hims...@louruppert.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. Why? By the time you're looking at it, there's nothing to do about what has been sent in the clear. It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. https is not a flag for TOP SECRET NSA PLAN FOR BACKDOORING THE UNIVERSE'S COMPUTERS OHS NOES! It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. Most of what is sent https is not even classified sensitive. If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? I suppose, if I'm looking for shoes for my wife's birthday, and it's supposed to be a surprise, and she regularly analyzes the house's router logs to check whether the kids are going to pornofthemonth.xxx, ..., but that's not the wireless router, come to think of it. Does your wife check your router logs? Okay, I suppose my son might, but, seriously. Oh, I suppose, if I were the kind of person to go to porn sites, I might decide not to return to such a site that sent me it's bd pics plaintext. (Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter?) Of course, if someone is tapping my stream and looking at the images I'm looking at, they probably also know what sites I'm connecting to. What I don't want is a site that claims to be 'secure' while leaking. Every site leaks. Secure pages that are blanket-sent TLS for the wrong reasons will not be analyzed for leaks, because the people who design the sight are unaware that TLS is not a big enough blanket. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Huh? Content creators and site managers probably want a tool that will highlight or red-circle elements on a page that are declared plaintext, and (as a different option or command) elements that will end up plaintext when the page is sent TLS. And they want the tool to walk their site automatically, leaving a log behind. Users want their browser to tell them when parts of the data in the query they send TLS are going to be sent plaintext. Some may want to know which elements are going to be sent plaintext. Some may want to scan for plaintext elements before they start filling in the form, so they don't waste their time. But they don't really care if the picture of the shoe or its title is being received plaintext. Such information is perceived as noise, unless they really are concerned about the off chance that someone might be capturing their data stream to find out what pictures or political rants they are accessing. Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? Surely you see that is not all that we are talking about? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. So, give them more data. Give them more of the hard data, in fact. We don't need to worry about debian repos becoming the key that allows them to develop that technique. Really? I mean, the current encryptions will be broken sooner or later. You're voting for sooner? I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. Yes, but except for freebsd's(?) mistake of using it exclusively, you'll find that OSes mix the entropy sources when providing /dev/random, and that
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:20 PM, Michael Stone wrote: On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: And you know, the funny thing is that MSIE took to warning people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for secured pages. You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. This kind of threat analysis is why so many of us are still skeptical of the need for HTTPS package mirrors. Mike Stone Do you have another idea for making it difficult for network observers to keep track of the software people are using? Do you think it does not matter that governments and companies are tracking the packages that people are downloading? .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53baecd7.3080...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:31 PM, Lou RUPPERT wrote: Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: As someone pointed out, verifying the mirror we've connected to is not useful when we don't particularly have, or want, a way to prevent a spook-owned mirror from joining the pool. OK so supposing the NSA offers its own mirror. The package installation process verifies PGP signatures. What is the actual scenario you're trying to prevent? apt repositories are great because the users do not have to rely on the servers that host the repositories in order to know that they packages are authentic and unmodified. Tor provides the same resilience in terms of privacy. If apt-get is accessing the NSA mirror using Tor, then even the NSA will not be able to see the IP address of the computer that is downloading from that mirror. And as long as apt does not leak much metadata, it would be quite difficult for the NSA to de-anonymize that connection. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/07/2014 13:09, Joel Rees wrote: Sorry Joel, I almost totally disagree with your vision on privacy and security, but I really i don't want to go into the merit of it, because I think Lou is representing my vision already; I only have a question: Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter? Can you proof it? Or maybe, you can tell the list what the attached image - that is encrypted with Moritz Muehlenhoff's and Florian Weimer's public keys - represent? Cheers (and thanks Mr. Moritz and Mr. Florian - who were the only I had in my keyring - to accept being the judges of the challenge). :-) Andrea Zwirner Sent from my Sylpheed image.jpg.gpg Description: Binary data
RFC: fail2ban wheezy security update
Dear Security Enthusiasts,
Would someone be kind to verify correct operation of a perspective security
update for the Fail2Ban package in wheezy. Especially if you are using
postfix, cyrus imap, courier smtp, exim, or lighttpd. Unfortunately amount of
changes to those filters definitions was quite large, and I have tried to do my
best to verify their correct operation on sample log lines we have in recent
Fail2Ban, but I could have missed something obvious since I have no working
deployments of postfix etc.
These changes will later me reapplied (where applicable) on top of the
squeeze LTS version as well (haven't looked into it yet).
I am attaching the debdiff and the .deb package could be found at
http://onerussian.com/tmp/fail2ban_0.8.6-3wheezy3_all.deb
signature: http://onerussian.com/tmp/fail2ban_0.8.6-3wheezy3_all.deb.asc
sha256sum: 815b28ffdfcfbf0c8983facad46d54edffce63df2269ef9dc79b60886e747794
If you prefer to review changes online, here is the corresponding
pull request: https://github.com/fail2ban/fail2ban/pull/757
Corresponding changelog, hinting on those filters which were affected by
the fixes -- the rest of the fail2ban should have not been affected
fail2ban (0.8.6-3wheezy3) wheezy-security; urgency=high
* Use anchored failregex for filters to avoid possible DoS. Manually
picked up from the current status of 0.8 branch (as of
0.8.13-29-g09b2016):
- CVE-2013-7176: postfix.conf - anchored on the front, expects
postfix/smtpd prefix in the log line
- CVE-2013-7177: cyrus-imap.conf - anchored on the front, and
refactored to have a single failregex
- couriersmtp.conf - anchored on both sides
- exim.conf - front-anchored versions picked up from exim.conf
and exim-spam.conf
- lighttpd-fastcgi.conf - front-anchored picked up from suhosin.conf
-- Yaroslav Halchenko deb...@onerussian.com Sun, 22 Jun 2014 11:56:54 -0400
Thank you very much and please CC me.
Best regards,
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
diff -u fail2ban-0.8.6/debian/changelog fail2ban-0.8.6/debian/changelog
--- fail2ban-0.8.6/debian/changelog
+++ fail2ban-0.8.6/debian/changelog
@@ -1,3 +1,19 @@
+fail2ban (0.8.6-3wheezy3) wheezy-security; urgency=high
+
+ * Use anchored failregex for filters to avoid possible DoS. Manually
+picked up from the current status of 0.8 branch (as of
+0.8.13-29-g09b2016):
+- CVE-2013-7176: postfix.conf - anchored on the front, expects
+ postfix/smtpd prefix in the log line
+- CVE-2013-7177: cyrus-imap.conf - anchored on the front, and
+ refactored to have a single failregex
+- couriersmtp.conf - anchored on both sides
+- exim.conf - front-anchored versions picked up from exim.conf
+ and exim-spam.conf
+- lighttpd-fastcgi.conf - front-anchored picked up from suhosin.conf
+
+ -- Yaroslav Halchenko deb...@onerussian.com Sun, 22 Jun 2014 11:56:54 -0400
+
fail2ban (0.8.6-3wheezy2) wheezy-security; urgency=high
* Anchor apache- filters failregexes to avoid possible DoS on servers
only in patch2:
unchanged:
--- fail2ban-0.8.6.orig/config/filter.d/couriersmtp.conf
+++ fail2ban-0.8.6/config/filter.d/couriersmtp.conf
@@ -5,6 +5,12 @@
# $Revision$
#
+[INCLUDES]
+
+# Read common prefixes. If any customizations available -- read them from
+# common.local
+before = common.conf
+
[Definition]
# Option: failregex
@@ -14,7 +20,10 @@
# (?:::f{4,6}:)?(?Phost[\w\-.^_]+)
# Values: TEXT
#
-failregex = error,relay=HOST,.*550 User unknown
+_daemon = courieresmtpd
+
+failregex = ^%(__prefix_line)serror,relay=HOST,.*: 550 User unknown\.$
+
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
only in patch2:
unchanged:
--- fail2ban-0.8.6.orig/config/filter.d/cyrus-imap.conf
+++ fail2ban-0.8.6/config/filter.d/cyrus-imap.conf
@@ -5,6 +5,12 @@
# $Revision$
#
+[INCLUDES]
+
+# Read common prefixes. If any customizations available -- read them from
+# common.local
+before = common.conf
+
[Definition]
# Option: failregex
@@ -14,10 +20,9 @@
# (?:::f{4,6}:)?(?Phost[\w\-.^_]+)
# Values: TEXT
#
-failregex = : badlogin: .*\[HOST\] plaintext .*SASL\(-13\): authentication
failure: checkpass failed$
- : badlogin: .*\[HOST\] LOGIN \[SASL\(-13\): authentication
failure: checkpass failed\]$
- : badlogin: .*\[HOST\] (?:CRAM-MD5|NTLM) \[SASL\(-13\):
authentication failure: incorrect (?:digest|NTLM) response\]$
- : badlogin: .*\[HOST\] DIGEST-MD5 \[SASL\(-13\): authentication
failure: client response doesn't match what we generated\]$
+_daemon = (?:cyrus/)?(?:imapd?|pop3d?)
+
+failregex =
Re: concrete steps for improving apt downloading security and privacy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: 2014/07/07 11:32 Lou RUPPERT hims...@louruppert.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. Why? By the time you're looking at it, there's nothing to do about what has been sent in the clear. There are sites now which have dynamic content. Imagine a site like Facebook, where there is so much content that it can't even fit on one page! As I already explained, the cleartext download warning isn't warning you about the data you're already looking at; it's warning you that the mechanism you're trusting may not be trustworthy. It's telling you stop now unless you understand the problem. Advice I'd recommend! It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. https is not a flag for TOP SECRET NSA PLAN FOR BACKDOORING THE UNIVERSE'S COMPUTERS OHS NOES! Not following you here. It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. Most of what is sent https is not even classified sensitive. Agreed. If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. Oh, I suppose, if I were the kind of person to go to porn sites, I might decide not to return to such a site that sent me it's bd pics plaintext. (Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter?) That's only if you don't include it inside of a stream with a bunch of other content, like http 1.1, for instance. Of course, if someone is tapping my stream and looking at the images I'm looking at, they probably also know what sites I'm connecting to. How about this scenario: Someone is installing software from a software catalog from a country where downloading software isn't illegal, but where people who download certain software are flagged as terrorists and made to undergo certain invasive scrutiny as a result. One catalog has the page served via https, but the software served via http, because they haven't upgraded their servers in a couple decades, and they own a lot of stock in the electric company. The other catalog has the whole content served via https. Which catalog do you think can install something like 'tor' without the user being watchlisted? Now update the scenario for an environment in which the nation state has a DPI border firewall and automatically stops downloads of certain software they don't like. Which catalog do you think will result in the user being able to successfully download what they need? (an interesting side effect from this is that the DPI site may decide to block the entire TLS-only catalog because of the lack of introspection, so maybe defaulting to an https mirror may have unintended consequences in such an environment?) What I don't want is a site that claims to be 'secure' while leaking. Every site leaks. Secure pages that are blanket-sent TLS for the wrong reasons will not be analyzed for leaks, because the people who design the sight are unaware that TLS is not a big enough blanket. Explain, please? Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? Surely you see that is not all that we are talking about? Nope. So what is the risk you're talking about, if not some key factoring plot? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. So, give them more data. Give them more of the hard data, in fact. Why
AUTO: Jan Hübner ist außer Haus (Rückkehr am 28.07.2014)
Ich bin bis 28.07.2014 abwesend. Eingegangene Mails werde ich nach meiner Rückkehr umgehend beantworten. In dringenden Fällen setzen Sie sich bitte mit Christian Pillat in Verbindung. Herr Christian Pillat Tel.: 040 / 73 41 93 - 701 E-Mail: christian.pil...@louis.de Mit freundlichen Grüßen Jan Hübner I will not be in office within the above mentioned time. Upon my arrival I will check and answer all emails immediately. In matter of urgency please don't hesitate to get in touch with Christian Pillat. Mr. Christian Pillat Tel.: 0049 40 / 73 41 93 - 701 E-Mail: christian.pil...@louis.de With best regards Jan Hübner Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht [SECURITY] [DSA 2973-1] vlc security update gesendet am 07.07.2014 23:38:12. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/of9b048ce5.154ec6e4-onc1257d0e.0078f318-c1257d0e.0078f...@louis.de
Re: RFC: fail2ban wheezy security update
I run a postfix at home, and I just installed your new package. It does look pretty good so far. Also reminds me I should pay more attention to my logs. There are a lot of attempts to connect from unauthorized people. Of course I'm sure that happens everywhere, which is why we use fail2ban in the first place! On Mon, 2014-07-07 at 17:55 -0400, Yaroslav Halchenko wrote: Dear Security Enthusiasts, Would someone be kind to verify correct operation of a perspective security update for the Fail2Ban package in wheezy. Especially if you are using postfix, cyrus imap, courier smtp, exim, or lighttpd. Unfortunately amount of changes to those filters definitions was quite large, and I have tried to do my best to verify their correct operation on sample log lines we have in recent Fail2Ban, but I could have missed something obvious since I have no working deployments of postfix etc. These changes will later me reapplied (where applicable) on top of the squeeze LTS version as well (haven't looked into it yet). I am attaching the debdiff and the .deb package could be found at http://onerussian.com/tmp/fail2ban_0.8.6-3wheezy3_all.deb signature: http://onerussian.com/tmp/fail2ban_0.8.6-3wheezy3_all.deb.asc sha256sum: 815b28ffdfcfbf0c8983facad46d54edffce63df2269ef9dc79b60886e747794 If you prefer to review changes online, here is the corresponding pull request: https://github.com/fail2ban/fail2ban/pull/757 Corresponding changelog, hinting on those filters which were affected by the fixes -- the rest of the fail2ban should have not been affected fail2ban (0.8.6-3wheezy3) wheezy-security; urgency=high * Use anchored failregex for filters to avoid possible DoS. Manually picked up from the current status of 0.8 branch (as of 0.8.13-29-g09b2016): - CVE-2013-7176: postfix.conf - anchored on the front, expects postfix/smtpd prefix in the log line - CVE-2013-7177: cyrus-imap.conf - anchored on the front, and refactored to have a single failregex - couriersmtp.conf - anchored on both sides - exim.conf - front-anchored versions picked up from exim.conf and exim-spam.conf - lighttpd-fastcgi.conf - front-anchored picked up from suhosin.conf -- Yaroslav Halchenko deb...@onerussian.com Sun, 22 Jun 2014 11:56:54 -0400 Thank you very much and please CC me. Best regards, -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1404772864.2925.3.ca...@jfergusdeb.proofpoint.com
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote: If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. I think you pulled out the only reason why using https for mirrors would be useful. The threat analysis doesn't show any practicable way for the any attacker to prevent alter packages even with control of the network. He could block updates but the client-side would noticed: out-of-date repository and package list, failed to download specific packages. HTTPS is a solution to this risk scenario: A) I don't want anyone to know which package I download (passive listening) B) I don't want a third party to selectively prevent me from downloading a package/update (active man i the middle) Scenario A is more likely to happen or to already be in place. HTTPS in this case is *not* about security but just privacy. 1) Performance concern: The CPU cycles for encrypting is now low enough so that it seems feasible. Not all package providers need to provide https-based repository but having a few of those and give them visibility would be greatly appreciated. 2) TLS certificates: we do not need the package to be behind a debian certificate, just to be behind a certificate trusted by a recognized third party (same requirement as for websites). Since we do not seek authentication of the package but just privacy, we only need to ensure that we talk to the server we wanted to, whichever it is. -- Jérémie MARGUERIE -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKS89GpjJtSNWcRvy2vJ4Jat97qmqPa2Q-=_x12yipw8qqq...@mail.gmail.com
AUTOMÁTICO: Fábio Rodrigues está ausente do escritório (retorna em 21/07/2014)
Estarei ausente do escritório até 21/07/2014 Nota: esta é uma resposta automática à sua mensagem [SECURITY] [DSA 2973-1] vlc security update enviado em 07/07/2014 18:38:12. Esta é a única notificação que você receberá enquanto esta pessoa estiver ausente. Uso responsável do papel, você tem um compromisso com o futuro. ** Informação transmitida destina-se apenas à pessoa a quem foi endereçada e pode conter informação confidencial, legalmente protegida e para conhecimento exclusivo do destinatário. Se o leitor desta advertência não for o seu destinatário, fica ciente de que sua leitura, divulgação ou cópia é estritamente proibida. Caso a mensagem tenha sido recebida por engano, favor comunicar ao remetente e apagar o texto de qualquer computador. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by person or entity other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ** -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/OFEB7832C4.8D8A700E-ON83257D0F.000666D0-83257D0F.000666D1@LocalDomain
External check
CVE-2014-3540: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ba438a.lLuRrODfP4ol+N/4%atomo64+st...@gmail.com
