- cypherpunks - lists.cpunks.org

Fwd: a catalog of bugs, or "Why to disable assembly optimization"
by coderman 24 Jul '14

24 Jul '14

---------- Forwarded message ---------- From: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> Date: Tue, Jul 22, 2014 at 12:23 PM Subject: a catalog of bugs, or "Why to disable assembly optimization" Folks: We had already agreed to disable assembly optimizations in pycryptopp, because there seem to have been a lot of bugs in the optimized assembly code in the past, and because the added speed really makes no difference to our uses, as far as I know. However, in order to explain and justify to other people (e.g. Debian packagers) why we are doing this, and why they should consider doing the same thing themselves, I just read through the entire history of issues in pycryptopp and classified whether they were runtime errors (and therefore potential security bugs) or build-time errors (therefore probably not), and whether they would have been avoided if we had been disabling assembly optimizations all along. Here are the results. They clearly show that we should disable the optimized assembly! About half of all the security-threatening bugs we've had would never have been an issue if we'd avoided assembly from the beginning. By the way, in my opinion the author of Crypto++, Wei Dai, is an *exceptionally* skilled, careful, and experienced coder, and I would assume that if Crypto++ has had this many security-threatening bugs in its optimized assembly code, then other crypto libraries that also use optimized assembly code also have at least as many. Here's the ticket to track this issue: https://tahoe-lafs.org/trac/pycryptopp/ticket/85 bugs that cause run-time failures ================================= (These bugs are potential security issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/24 - https://tahoe-lafs.org/trac/pycryptopp/ticket/31 - https://tahoe-lafs.org/trac/pycryptopp/ticket/45 (three *different* bugs in the assembly implementation) - https://tahoe-lafs.org/trac/pycryptopp/ticket/67 - https://tahoe-lafs.org/trac/pycryptopp/ticket/84 - https://tahoe-lafs.org/trac/pycryptopp/ticket/86 * unclear if it would have been avoided if we'd used DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/65 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/17 - https://tahoe-lafs.org/trac/pycryptopp/ticket/44 - https://tahoe-lafs.org/trac/pycryptopp/ticket/83 * would not have been avoided by DISABLE_ASM (but would have been avoided by using cffi instead of CPython API) - https://tahoe-lafs.org/trac/pycryptopp/ticket/19 - https://tahoe-lafs.org/trac/pycryptopp/ticket/70 - https://tahoe-lafs.org/trac/pycryptopp/ticket/80 * would have been avoided if we *didn't* use DISABLE_ASM! (A bug only in the non-ASM version!) - https://tahoe-lafs.org/trac/pycryptopp/ticket/66 bugs that cause deterministic build or compilation failures =========================================================== (These bugs are *typically* not potential security issues but they can be, and in any case they are engineering/deployment issues.) * would have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/37 - https://tahoe-lafs.org/trac/pycryptopp/ticket/96 * would not have been avoided by DISABLE_ASM: - https://tahoe-lafs.org/trac/pycryptopp/ticket/22 - https://tahoe-lafs.org/trac/pycryptopp/ticket/23 - https://tahoe-lafs.org/trac/pycryptopp/ticket/32 - https://tahoe-lafs.org/trac/pycryptopp/ticket/39 - https://tahoe-lafs.org/trac/pycryptopp/ticket/62 - https://tahoe-lafs.org/trac/pycryptopp/ticket/77 - https://tahoe-lafs.org/trac/pycryptopp/ticket/78 -- Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters.

2 1

Tails vulnerability specific to I2P, not Tor
by Eugen Leitl 24 Jul '14

24 Jul '14

http://blog.exodusintel.com/2014/07/23/silverbullets_and_fairytails/ SILVER BULLETS AND FAIRY TAILS Introduction This week we made mention on Twitter of a zero-day vulnerability we’ve unearthed that affects the popular Tails operating system. As the Tails website states: Tails is a live operating system, that you can start on almost any computer from a DVD, USB stick, or SD card. It aims at preserving your privacy and anonymity, and helps you to: use the Internet anonymously and circumvent censorship; all connections to the Internet are forced to go through the Tor network; leave no trace on the computer you are using unless you ask it explicitly; use state-of-the-art cryptographic tools to encrypt your files, emails and instant messaging.” This software was largely popularized due to the fact that it was used by whistleblower Edward Snowden. Since then, the OS has garnered much attention and use by a wide range of those seeking anonymity on the Internet. We publicized the fact that we’ve discovered these issues for a very simple reason: no user should put full trust into any particular security solution. By bringing to light the fact that we have found verifiable flaws in such a widely trusted piece of code, we hope to remind the Tails userbase that no software is infallible. Even when the issues we’ve found are fixed by the Tails team, the community should keep in mind that there are most certainly other flaws still present and likely known to others. Our customers use our information for both offensive and defensive purposes to better protect themselves and others. Providing a wide variety of exploit software we help penetration testers effectively test network security and incident response teams. One high profile example occurred last year when Facebook used a zero-day vulnerability to test their teams response to a zero-day attack. The information we provide is also leveraged in defensive purposes providing companies with well documented research for use in IDS and AV signatures for previously unknown threats. We at Exodus are able to do what many software projects cannot, perform security code audits and find exploitable vulnerabilities releasing them to the public. The Vulnerable Component The vulnerability we will be disclosing is specific to I2P. I2P currently boasts about 30,000 active peers. Since I2P has been bundled with Tails since version 0.7, Tails is by far the most widely adopted I2P usage. The I2P vulnerability works on default, fully patched installation of Tails. No settings or configurations need to be changed for the exploit to work. I2P is preconfigured so that all .i2p TLD sites are routed through the I2P network. At a high level I2P traffic is message based similar to IP packets. All communication is encrypted end to end with a total of four layers of encryption. I2P routers (end points) act as cryptographic identifiers, similar to a pair of public keys. I2P is a packet switched network, instead of circuit switched like Tor. This means transparent load balancing of packets across multiple peers. I2P is fully distributed with no centralized resources. There is no distinct separation of servers to nodes, this architecture helps eliminate single points of failure. Demonstration To lend credence to our claims we have created a video that demonstrates de-anonymizing a Tails user: TailsDeAnonymizationTailsDeAnonymization ► Timeline 0:00:00,000 –> 0:00:10,400: Demonstrating IP on listening server, Turning on listening server 0:00:19,000 –> 0:00:25,400: Tails user visiting website icanhazip.com which shows the anonymized IP address 0:00:36,000 –> 0:00:49,400: Showing that we’re indeed using the latest Tails build 1.1 0:00:50,000 –> 0:01:03,400: I2P address being resolved, proof of concept malicious payload being delivered 0:01:30,000 –> 0:01:40,400: Listening server retrieves the Tails user’s de-anonymized IP address (Austin RoadRunner ISP) Note on Disclosure Disclosure of vulnerabilities takes many forms, particularly their shape is adapted to the landscape that the platform is used upon. In the past at Exodus Intelligence, we’ve felt that significant vulnerabilities have been disregarded and have not had the requisite exposure. Through appropriate airing of the issue, we feel that users of such security platforms may come to understand the risks in base-level trust. Even further we hope to break the mold of unconditional trust in a platform. Users should question the tools they use, they should go even further to understand the underlying mechanisms that interlock to grant them security. It’s not enough to have faith upon security, rather to have an understanding of it. If the public thinks Exodus is one of a few entities finding bugs in software, they are grossly misinformed. As is the case with all vulnerabilities we report to vendors, we do not ask for any remuneration. All flaws that we give to vendors are given free of charge. All accusations of extortion perpetuated by those unfamiliar with our business model are completely unfounded. As of publication of this blog post the Tails team and the I2P team have both received all the relevant details and exploit code they require to remediate the vulnerabilities we’ve discovered. Recently a high profile talk on de-anonymization Tor users was pulled from Blackhat due to legal issues. Their talk outlined with a budget of $3000 with some powerful servers and multiple gigabit links they were able to de-anonymize hundreds of thousands of users in ‘a couple of months’. Exodus decided to pick up where this talk left off by letting the community know that there are many other vectors for de-anonymization. The vulnerability we have found is able to perform remote code execution with a specially crafted payload. This payload can be customized to unmask a user and show the public IP address in which the user connected from within ‘a couple of seconds’. Stay Tuned Part two of this blog post will present a technical discussion of the vulnerability. This will be posted once we have confirmed the vulnerabilities in I2P are patched and have been incorporated into Tails.

2 1

OT: List Archives
by grarpamp 24 Jul '14

24 Jul '14

Can mailman be configured to include the 'To:' and 'Cc:' addresses in the archive gz's? It would add some needed context when locally combining/splitting multiple lists for MUA use. And is there a way retrieve monthly attachment gz's without needing to fetch per attachment? Also, how is the 'since inception' archive project coming?

2 1

Gruveo, more secure skype alternative?
by unixninja92 24 Jul '14

24 Jul '14

Recently found Gruveo[1]. Allows easy video and audio calls similar to cryptocat. Unfortunately not open source and makes no mention of being audited. Otherwise looks very interesting and promising. It tries to use P2P to make calls, and if it fails, then it will go through their servers. Uses WebRTC for end to end encrypted audio and video chat. They claim they don't keep any logs that could identify users. So the question is, is this an NSA honey pot or something that might actually be trustworthy? It seems at least a bit more secure/trustworthy than skype to me. [1] https://www.gruveo.com/

9 8

Increased and Diverse Disclosure Initiatives Needed
by John Young 24 Jul '14

24 Jul '14

Cryptome has canceled the Kickstarter. Following the purpose of the kickstarter it urges support for increased and diverse disclosure initiatives. A few suggestions: 1. Many more and diverse disclosure initiatives are needed to broaden public participation, to diversify content and to increase unpaid access. 2. They should be novel and unexpected. 3. They should evolve and avoid being static, preferrably brand-free. 4. These may be online, offline or neither, inventive and variable. 5. They may be short- or long-lived or episodic and erratic. 6. Might be hit and run, for a single disclosure or unpredictable series. 7. Provided by individuals, groups or variable. 8. Funded by individuals, groups or variable. 9. Anonymous, nonymous, pseudononymous or variable. 10. Legal, extra-legal, quasi-legal, pushing against legal or variable. 11. Low-key, low-profile, low-recognition, the opposite or variable. 12. Reputable, disreputable or variable. 13. Risky, dangerous, outrageous, the opposite or variable. 14. Citizens' duty should be to disclose, resist secrecy, official secrecy most so.

1 0

Re: [Cryptography] hard to trust all those root CAs
by grarpamp 23 Jul '14

23 Jul '14

On Sat, Jul 19, 2014 at 5:03 PM, John Denker <jsd(a)av8n.com> wrote: > AFAICT, a lot of existing protocols were designed to resist > passive eavesdropping. In contrast, the idea of large-scale > MITM attacks was sometimes considered tin-foil-hat paranoia. > To this day, standard Ubuntu Firefox trusts 162 different > authorities (including the Hong Kong Post Office) to certify > /anything and everything/. > > In the /usr/share/ca-certificates/mozilla directory, only one > of 163 root certificates has any v3 Name Constraints at all. > Why Ubuntu and Firefox tolerate this is beyond me; I can > understand trusting Microsoft to sign Microsoft-related stuff, > but allowing them to sign /anything and everything/ ?!????!! The mozilla bundle includes about 150. It would be nice if the new cert observatoris publish a count of how many end certs they see each root cert covers... a topN list of sorts. Then you could save some time by including the N of your choice into your 'empty by default' list. I think the distribution would be severly skewed to maybe top 10 or 15 covers most any place.

2 2

Re: Gruveo, more secure skype alternative?
by John Preston 23 Jul '14

23 Jul '14

You can find the results of my inquiry below. ¬_¬ -------- Forwarded Message -------- > From: Art Matsak <art(a)gruveo.com> > To: John Preston <gizmoguy1(a)gmail.com> > Subject: Re: Security specifics > Date: Wed, 23 Jul 2014 18:34:28 +0200 > > Hi John, > > Thank you for your interest in Gruveo. Gruveo uses WebRTC, an open technology for browser realtime communication. You can find details on its security architecture here: > > http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 > > Please note that WebRTC is work in progress and its specifications may change in the future. > > To answer your other questions, Gruveo is a proprietary product. > > Best regards, > > Art Matsak > Founder and CEO > Gruveo > https://www.gruveo.com > > > On 23 Jul 2014, at 18:19, John Preston <gizmoguy1(a)gmail.com> wrote: > > > From: John Preston <gizmoguy1(a)gmail.com> > > Subject: Security specifics > > > > Message Body: > > Hey all, > > > > Like the idea, but I'd like to know about the specifics of how Gruveo is designed. Specifically: > > * what is the threat model? > > * what are the network protocol specifications? Packet formats, ciphers and modes, and semantics all critically determine the security of the system. > > * who owns the IP, and how is it licensed? > > * what's the development model like? > > > > Thanks for your time, :) > > John > > > > -- > > This mail is sent via contact form on Gruveo https://www.gruveo.com > >

2 1

Compromise of Soviet codes in WWII
by grarpamp 23 Jul '14

23 Jul '14

http://chris-intel-corner.blogspot.gr/2014/07/compromise-of-soviet-codes-in… Overview of Soviet cryptosystems The secretive Soviet state used various cryptosystems in order to secure its communications from outsiders. The task of preparing and evaluating cipher procedures was handled by two main Soviet organizations, the NKVD’s 5th Department and the Army’s 8th department of the main intelligence directorate GRU. In the 1920’s simple substitution systems were used and these were solved by ...

1 0

Alleged IOS backdoors
by Georgi Guninski 23 Jul '14

23 Jul '14

Alleged IOS backdoors http://www.zdziarski.com/blog/wp-content/uploads/2014/07/iOS_Backdoors_Atta… Identifying Back Doors, Attack Points, and Surveillance Mechanisms in iOS Devices JONATHAN ZDZIARSKI

4 4

Tor developers vow to fix bug that can uncloak users
by Eugen Leitl 23 Jul '14

23 Jul '14

http://arstechnica.com/security/2014/07/tor-developers-vow-to-fix-bug-that-… Tor developers vow to fix bug that can uncloak users Weakness was topic of talk abruptly pulled from security conference. by Dan Goodin - July 22 2014, 8:15pm CEST Developers of the Tor privacy service say they're close to fixing a weakness that researchers for an abruptly canceled conference presentation said provides a low-cost way for adversaries to deanonymize hundreds of thousands of users. The talk previously scheduled for next month's Black Hat security conference in Las Vegas was titled "You Don't Have to be the NSA to Break Tor: Deanonymizing Users on a Budget." The abstract said that the hack cost less than $3,000 and could uncloak hundreds of thousands of users. On Monday, Black Hat organizers said the presentation was canceled at the request of attorneys from Carnegie Mellon University (CMU), where the researchers were employed, as well as the Software Engineering Institute (SEI). The attorneys said only that the materials to be presented "have not yet been approved by CMU/SEI for public release." Researchers Alexander Volynkin and Michael McCord have yet to explain why their talk was pulled. Tor officials responded by saying that they're working on an update for individual Tor relay nodes that will close the unspecified security hole. "Based on our current plans, we'll be putting out a fix that relays can apply that should close the particular bug they found," Tor project leader Roger Dingledine wrote in an e-mail to Tor users. "The bug is a nice bug, but it isn't the end of the world. And of course these things are never as simple as 'close that one bug and you're 100% safe.'" He said the fix was complicated because the researchers didn't provide all the technical details when privately informing Tor officials of the vulnerability. "We've been trying to find delicate ways to explain that we think we know what they did, but also it sure would have been smoother if they'd opted to tell us everything," he wrote. "The main reason for trying to be delicate is that I don't want to discourage future researchers from telling us about neat things that they find. I'm currently waiting for them to answer their mail so I can proceed." In a previous e-mail, Dingledine said Tor developers "informally" received some materials related to the vulnerability. He went on to say Tor officials played no role in the cancellation of the Black Hat talk. "We did not ask Black Hat or CERT to cancel the talk. We did (and still do) have questions for the presenter and for CERT about some aspects of the research, but we had no idea the talk would be pulled before the announcement was made," he wrote. CMU is affiliated with CERT, which coordinates security disclosures between researchers and affected parties. A CMU spokesman contacted Monday didn't elaborate on the reasons for pulling the talk.

2 1