Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions + Cautions #90

Closed
taoeffect opened this issue Feb 10, 2016 · 13 comments
Closed

Suggestions + Cautions #90

taoeffect opened this issue Feb 10, 2016 · 13 comments

Comments

@taoeffect
Copy link

  • Recommend Ricochet over Adium, as Adium hasn't really received significant update in a while. EDIT: it's been over a year since its libpurple was updated, and I'm pretty sure I recall libpurple having had multiple security related issues in that timespan.
  • Prioritize Firefox over Chrome. Firefox, IMO, is a vastly more capable browser and most importantly it doesn't install crap on your drive that runs as root and periodically downloads software from the internet. See Google Chrome is an APT and this and related work by Todd. Also, Firefox's devs seem to take security more seriously than Chrome's (see this post and the note at the bottom).
  • Do not recommend any software by Objective-See / Patrick Wardle. He's an ex-NSA employee who refuses to open source the free software that he's giving away on his website. He refuses to explain why, and gives disingenuous responses when asked.
@taoeffect taoeffect changed the title Suggestions Suggestions + Cautions Feb 10, 2016
@ajkblue
Copy link

ajkblue commented Feb 10, 2016

The latest piece of software from Patrick Wardle/Objective See called "Ostiarius" is actually open-source, see https://objective-see.com/products/ostiarius.html

@taoeffect
Copy link
Author

See called "Ostiarius" is actually open-source, see https://objective-see.com/products/ostiarius.html

It seems to be only partially open source (like KnockKnock). The kext is open source but the GUI is not, so there's no way for anyone to build a useable version of it for themselves.

Also, I added this edit to my comment above to clarify why Adium not updating its libpurple in almost two years is a security issue:

EDIT: it's been over a year since its libpurple was updated, and I'm pretty sure I recall libpurple having had multiple security related issues in that timespan.

@taoeffect
Copy link
Author

The kext is open source but the GUI is not, so there's no way for anyone to build a useable version of it for themselves.

Let me clarify that a bit: there is a way for folks to build a usable version of it themselves, but 99.99% will not because they will be left with a kernel extension and not knowing how to use it.

There is the obvious problem of an ex-NSA employee distributing a binary that asks for your root password. The build is not a deterministic build so it would require an expert to disassemble it and verify that there's no funny-business going on.

Then there's the issue of not providing any reason (at all) for not open sourcing everything.

Let's go over it again:

  • An ex-NSA employee
  • Who is an expert in writing rootkits
  • Is asking you to install what could very well be a rootkit on your computer
  • And refuses to give you the source to it or explain why

@drduh
Copy link
Owner

drduh commented Feb 10, 2016

Thanks for taking a look, Greg. Your insights are very much appreciated.

  • I will certainly take a look at Ricochet. I know Adium's apparent stalled development does not inspire much confidence, but I felt it was "secure enough" to recommend as a general guideline for a XMPP client. The lack of libpurple updates is not great, so I'll have a look to see why (iirc, last I had checked, there weren't any critical, unpatched issues, but that may have changed now). I had noticed the developer updated Adium to address the Sparkle vulnerability quite quick, which is a good sign.
  • It is a valid criticism you make of Chrome, but I would argue the benefit of a self-updater mechanism may outweigh the risk of having a browser which needs to be manually updated. What's more, I don't believe Firefox's sandbox work to be complete at this time (https://wiki.mozilla.org/Security/Sandbox#MacOS_X_Firefox), which leaves a lot to be desired. There's been some discussion about browser preference in another issue, but I will read your cited material and possibly make adjustments, or alter the recommendation to use Chrome altogether. Let me think about this one.
  • Great point about Patrick's closed source apps. I would like to give him an opportunity to respond to your comments (paging @patrickwardle) before assuming his efforts are malign in some way. I've actually discouraged the use of closed-source software whenever possible in the start of the guide, but maybe it's not clear enough.

Greg, thank you again for having a read through the guide and offering your thoughts. If there's any other suggestions you can make, please let me know, or make a pull request.

@patrickwardle
Copy link

Aloha,

First, thanks for including a link to my blog and providing an opportunity for me to respond.

The tools on Objective-See.com are simply the personal tools I run on my Mac to keep myself secure. I figured freely sharing them on my personal site might be useful to other Mac users.

Obviously there are pros & cons and endless debates about open-source vs. closed-source. I've thought a lot about this, however to protect my personal IP, I decided to keep various components close-sourced. This seems to align with the majority of software that is distributed for OS X, especially in terms of security software. Of course I understand some people will passionately disagree with this.

I think the following points are relevant as well:

  • I've released open-source versions of several of my tools (e.g https://github.com/synack/knockknock, https://github.com/synack/DylibHijack)
  • All kernel-components are open-sourced, and in the future I'll likely open-source more and more components. Some (such as the Ostiarius kext), can be used in a completely stand-alone manner)
  • My tools contain (and never will!) no adware, no tracking, nor collect any data/metrics about end-users (edit: nor malware, backdoors, exploits, trojans, hidden functionality, etc. etc)
  • All network connections generated by my tools (version checks/queries to VirusTotal) are clearly explained and documented
  • All persistent components (e.g. BlockBlock's daemon, etc) are clearly documented - and uninstallers and manually instructions for fully uninstalling such persistent components are always provided
  • The tools contain no obfuscations nor encrypted code nor auto-update logic

I have no problem with people disagreeing with my approach - but I'd rather keep reporting security vulnerabilities to Apple and releasing free tools to protect Mac users, than spend a lot of time arguing on the internet ;)

@taoeffect
Copy link
Author

I've thought a lot about this, however to protect my personal IP, I decided to keep various components close-sourced.

I see. Well thanks for finally providing a reason, albeit one I find hard to understand. What is so important about the IP in a tiny Cocoa app to install/uninstall a kernel extension?

This seems to align with the majority of software that is distributed for OS X, especially in terms of security software.

Most of those tools are:

  1. Being charged for.
  2. Not written by ex-NSA rootkit experts.

Sorry, but there's a higher bar of scrutiny for ex-NSA rootkit experts to go over, especially those who aren't super willing to give convincing answers to simple questions.

I've released open-source versions of several of my tools (e.g https://github.com/synack/knockknock, https://github.com/synack/DylibHijack)

KnockKnock is not fully open source, and the issue is that, so far as I can tell, 100% of the software on your "Free OS X Security Tools" page is not fully open source.

In a world of many non-NSA employees happily giving the source away to their "Free OS X Security Tools", your behavior is deeply suspect.

My tools contain (and never will!) no adware, no tracking, nor collect any data/metrics about end-users

Those were never the concern. It's interesting you left out the actual concern: backdoors.

I'd rather keep reporting security vulnerabilities to Apple and releasing free tools to protect Mac users

If that's all you're doing, kudos and more power to you. If it's not, well, I'd hate to be in your shoes when someone finds out.

@ghost
Copy link

ghost commented Feb 12, 2016

Hi there,

I'm agree for libpurple situation and as discussed with @taoeffect, Google Chrome does not install a updater daemon as root by default but use the current user's privilege (at least now) but I'm agree with https://twitter.com/taoeffect/status/697891999068721152 / https://twitter.com/pwnsdx/status/697892634749247489 though.

Regarding Objective-See's @patrickwardle apps, I reverse engineered as I could BlockBlock / Ostiarius (binaries/kexts) and here is my thought about him:

  • For Ostiarius, it does not emit any network connections and the distributed binary seems faithful to the sources.
  • For BlockBlock, it does not emit any network connections except updates checks (only if activated and with user privileges), the kext is very small and it use com.apple.kauth.vnode to watch files activity.

So I think he is honest but despite my checks, I can not guarantee the presence of intentional/unintentional vulnerabilities so I don't understand why you are not opening the full sources so we all can look into it and be sure there is no nasty things inside. I think it's essential if you want to gain trust especially because it is a security-related software and because of where you worked before. And by assuming there is no backdoor now, they could ask you to put a backdoor inside the next BlockBlock update. Nobody will know about it so think about it.

PS: @taoeffect, could you please provide a proof that @patrickwardle actually worked for the NSA?

@taoeffect
Copy link
Author

Google Chrome does not install a updater daemon as root by default but use the current user's privilege (at least now)

Yeah I'm curious to try it out again and see what the deal is with the latest versions (it certainly used to install the root daemon, as Todd's research is clear evidence of).

For Ostiarius, it does not emit any network connections and the distributed binary seems faithful to the sources.

Cool, so you did end up comparing it against one you compiled (and you're certain)? If so that's good news.

PS: @taoeffect, could you please provide a proof that @patrickwardle actually worked for the NSA?

Just put "patrick wardle nsa" (no quotes) into a search engine.

@ghost
Copy link

ghost commented Feb 12, 2016

Hello,

Cool, so you did end up comparing it against one you compiled (and you're certain)? If so that's good news.

As I said it seems so I'm not certain.

Just put "patrick wardle nsa" (no quotes) into a search engine.

Thanks.

@taoeffect
Copy link
Author

FYI, Ricochet 1.1.2 just released, and it includes an audit report! 😄
https://github.com/ricochet-im/ricochet/releases/tag/v1.1.2

@ghost
Copy link

ghost commented Feb 22, 2016

Thanks for the link, very nice report.

@drduh drduh closed this as completed in b44bae9 Mar 2, 2016
@taoeffect
Copy link
Author

Great stuff @drduh!

@kristovatlas
Copy link

Interesting discussion here, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants