Multiple Vulnerabilities in Pocket (opens in new tab)

   -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    # Create a chain for outgoing proxy traffic
    -N PROXY_OUT
    -A OUTPUT -m owner --uid-owner proxy -j PROXY_OUT

    # Allow replies to the requestor
    -A PROXY_OUT -p tcp --sport 8080 -j ACCEPT

    # Prevent proxy from talking to anything non HTTP{,s} (and DNS)
    -A PROXY_OUT -p tcp -m multiport ! --dports 80,443,53 -j DROP
    # Allow DNS udp
    -A PROXY_OUT -p udp --dport 53 -j ACCEPT

    # Allow the proxy to specific private ips (demos servers)
    -A PROXY_OUT -d xxx.xxx.xxx.xxx/32 -j ACCEPT

    # Prevent proxy from talking to anything private
    -A PROXY_OUT ! -o <%= @public_iface %> -j DROP
    -A PROXY_OUT -d 10.0.0.0/8 -j DROP
    -A PROXY_OUT -d 172.16.0.0/12 -j DROP
    -A PROXY_OUT -d 192.168.0.0/16 -j DROP

    # Prevent proxy from talking to services via public ips
    <% @aws_public_ips.each do |name, facts| %>
    # <%= name %>
    -A PROXY_OUT -d <%= facts['ec2_public_ipv4'] %>/32 -j DROP
    <% end %>

Anything I missed? Blocking outgoing ports is to taste.

For those who don't know about uid-owner. Here's how you would block any process running as the "mike" user from accessing anything on localhost:

iptables -A OUTPUT -m owner --uid-owner mike -d 127.0.0.0/8 -j REJECT

ip6tables -A OUTPUT -m owner --uid-owner mike -d ::1 -j REJECT

Also, it can be expressed without the dots. e.g. http://2130706433

Also:

  $ ping 2130706433
  PING 2130706433 (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.043 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.106 ms
  ^C

Dotted quad is just a convenient representation of an unsigned int.

localhost.fbi.gov is a great example. (Also a great way to exfiltrate fbi.gov cookies on a multi-user system, but that's another discussion completely.)

If you run an open proxy, then you're choosing to give away any privileges you've received on the basis of your network position or IP. By default, one should avoid running open proxies.

They should have run the proxy on a host that they didn't give any special IP-based privileges to. The other nodes shouldn't honor X-Forwarded-For headers from the IP hosting the proxy.

In OS X you have to add aliases on the loopback interface for 127/8 addresses other than 127.0.0.1 to respond.

> Pocket began life as a Firefox add-on

And that's what it should have remained! Promote it all you like on your websites, but please let it, and all featurees like it, be separate from the main web browsing functionality, because far from every one of your users wants or needs this!

I, and I'm sure many other Firefox users are deeply disappointed by the Mozilla track record of including questionable features such as this. That's why, I have already started [1] figuring out how to switch to ESR channel by default on all systems that I have control over: I want the security updates, but I don't have the time and effort necessary to browse through all the crap features Mozilla introduces and figure out how to tweak and/or disable them on a six-week basis.

[1] http://askubuntu.com/q/659246/181242

I could care less about their being a third party--we already have that with the search bar (and it's been promised that Pocket integration was just a step towards a more general Reading list API, though I don't know how well that's been followed through with). What annoys me is that baking features like Hello and Pocket into the browser doesn't strike me as "promoting openness, innovation & opportunity on the Web," it just seems like a desperate attempt to regain market share.

I believe the root of this change-in-mission is well expressed in a post by David Rajchenbach-Teller [1]:

  While I personally want a browser that is fast, small, reliable
  and trustworthy, we have market research that shows us that you
  and I are a minority. More precisely, we have market numbers
  that shows that users want a Pocket-like feature and are not
  going to bother checking if there are add-ons that implement
  it.

I would be very surprised if the kind of users who won't check for addons are also the kinds of users who would go out of the way to change their browser (... or even know what a browser is).

[1] https://groups.google.com/d/msg/mozilla.governance/2PYq2w8te...

> We chose the latter

And as a long-time user of Firefox, this is what got me to stop using Firefox.

There's been tons of people asking for the removal of Pocket from Firefox including hundreds of posts in the Mozilla governance forum asking for its removal but Mozilla sits there doing nothing claiming "sane privacy" and "oh you can disable it by going to your about:config and finding this key and setting it to false". Package it as an uninstallable extension or get rid of it completely.

I use Firefox partly because I thought Mozilla's definition of "sane privacy and data access policies" involved client-side encryption. My parents understood that Mozilla couldn't see their bookmarks; now they understand that Mozilla can see some of their bookmarks but aren't sure which. Even if I didn't care about my personal privacy, I still couldn't use Pocket at work because of company policy.

Bloat like pocket/hello is a trap. The original mozilla suite had e-mail, a newsgroup reader, irc chat and html development tools all embedded. Sounds useful, but who used it? Only power users and enthousiasts. I imagine a share of users are enthousiastic about pocket, but it also subtily makes the whole browser less attractive.

Complexity intimidates and scares off users and makes software harder to use. All firefox' competitors are extremely streamlined and simple, and that works. Firefox got popular intially because it was simple. Chrome became popular fast because it was faster and more streamlined than firefox. And by integrating all these extra services, firefox makes itself less streamlined and less useable.

I stick with firefox because chrome has some dubious privacy defaults, but that's really the only advantage firefox has over its competitors from my perspective.

fwiw, I actually use Firefox (I say that because I assume most of the complainers don't) and was thinking of making my own reading-list service, but Firefox integrating with Pocket saved me the trouble. I use the integration many times a day and it's great. Not sure why this gets so much negative attention (it's not like it's spying on you if you don't use it).

That actually makes it worse. At least if there was a transaction between two companies, I would've undertood Mozilla's decision. Now it makes zero sense.

One way would be to keep forking Firefox's codebase for bug fixes and new features while customizing it to fit the needs of the privacy conscious users. It may not be "ethical" but it will serve the main premises of open source and is also doable as a community. A new name would also be required as Firefox is trademarked by Mozilla (See Iceweasel Browser [1]).

[1] https://wiki.debian.org/Iceweasel

Jon von Tetzchner. He's got a team of experienced browser devs and fuck-you money from selling his last browser company.

Here's a picture of their current team: https://getpocket.com/jobs - Here's a list of 7 other positions they're currently hiring for - https://boards.greenhouse.io/pocket

This isn't some free service being run out of the goodness of somebodys heart. This is a company, that wants to make money. If a company has that many employees, they can afford a bug bounty program too.

Uh, they've raised $14.5 million[0] and have over 17 million users. This isn't a side project. Not by a long shot.

[0] https://www.crunchbase.com/organization/pocket

I disagree. Mozilla signs a very rich contract with search engines like Google and Yahoo. They have more money than they know what to do with.

Yes. Notice the corollary: if they had a bug bounty, we wouldn't be learning about this today, because someone who wants to make money probably would have already found them.

You shouldn't do work based on "they haven't had a bug bounty before now but maybe they will make one just for me."

They also don't really seem to put much effort into releasing bugfixes in a timely manner. For a month and a half, you could reboot any iPhone in the world remotely via text message.

Heaven forbid we ask of a corporation that they compensate us for a job they should have done and preventing huge losses and a PR nightmare.

Had I been OP I would have sold the exploits with no remorse, we don't need companies like that on the market, rewarding corporations for bad behaviour with free labour is fucked up on every level.

Yep, we use HTTP::Tiny::Paranoid with additional blocklists for all external requests at FastMail. We have to allow requests to hit our external IPs still, because our customers could be fetching public data from other customers - but the requests route out to the external network, and our machines don't trust the external network more than they trust any other part of the internet.

It would, but it's quite easy to miss something in the actual implementation:

- How do you extract the hostname from the URL? If the algorithm isn't the same as the one used by your network lib, it might be possible to trick your check into checking the wrong hostname.

- You'd have to check for redirects.

- If you pre-resolve DNS hostnames for your check, and then let your network lib open another socket to the host, it might resolve to another (internal) IP, because the attacker might control the DNS zone of that host, returning 127.0.0.1 on every other request. You'd have to make sure to open a socket to the IP returned during the check.

The safer option would be to work with iptables: https://news.ycombinator.com/item?id=10079554

There was also the address of the other internal services.

I think the best way here is to put the "fetch random URLs" service out in its own subnet, where it cannot access any other internal services like the EC2 status service. You'll also have to validate the URLs (no non-HTTP-or-HTTPS URLs) and prevent things like the redirect attack from working.

To be honest I think you're trying to come up with an explanation for the unexplainable. Running absolutely nothing as root is Security 101

> a system administrator with an eye for deployment best practices

Many companies call this position "DevOps Manager" or something similar. They usually own their servers, manage builds and deploys, maintain the repos, and communicate to management and developers.

> running something as root avoids a whole class of deploy problems

Only one class of deploy problems: you're not at all familiar with Linux or other Unix clones.

I agree but partially.

We are not talking about some complex interactions between multiple components which lead to a security vulnerability. This is some trivial stuff like "don't give your passwords to anybody" or "don't run everything as root".

The most complex vulnerability mentioned in the article is with proxying. If you have opened /etc/squid/squid.conf at least once you should have noticed the to_localhost ACL and the comments which explain why it is important. So is the Pocket team building a multi-million user service which has a proxying component without trying to configure squid once? Absolutely!

Also I consider too optimistic hoping for the situation to improve - it's moving in the opposite direction for now with steady speed.

> It's not the DevOps philosophy that's to blame. That philosophy is primarily about the utilization of automation to drive deployments.

In theory it is. In practise it sometimes seems to be seized on by people who are sick of listening to those fuddy-duddy infrastructure types bang on about security and firewalls and ug, so boring bro. Crush code!

“opt-out” is certainly correct (though, as I understand it, Pocket, as with all parts of Firefox, is only loaded when it is actually used, so “opt-out” does not seem to tell the whole story to me). I do disagree with the “non-removable” bit. Fully disabling it, to me, counts as removable (though I can understand why someone would disagree).

Perhaps I just read something into the Author's tone (probably due to all the vitriole from the typical discourse around the integration) that wasn't really there. If that's the case, and all the author meant by that statement was that the code itself could not be completely erased from Firefox as-packaged, then that seems to be factually true, and I simply read it incorrectly.