
Multiple Vulnerabilities in Pocket - ers35
https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/
======
jerf
A little tip for people trying to armor themselves against this problem: If
your app reaches out to do network transactions, it really ought to block
localhost. However, bear in mind that localhost isn't "127.0.0.1"... it's
"127.0.0.0/8" (or "127.x.x.x" if you don't casually speak CIDR). Ping
127.2.88.33 on your console now... you'll see replies.

On the flip side, if you're doing a security test like this, I've gotten
mileage out of convincing apps to access local resources with things like
127.88.23.245, precisely because the developer blocked 127.0.0.1 specifically
and thought they were done.

You should also usually block all internal and external IPs for your entire
network, but especially in the cloud this can begin to get tricky. Still, you
should.

And don't forget IPv6.

~~~
pfg
Also worth noting: don't just regex-check the URL with (localhost|127.*) or
something similar. Any hostname could point to 127.0.0.1.

iptables with --uid-owner denying traffic to local/private IP space (plus
infrastructure-specific stuff like EC2's instance metadata service) would
probably be the best option.

~~~
dunham
Also, it can be expressed without the dots. e.g.
[http://2130706433](http://2130706433)

~~~
knodi123
that is how I got around all the internet filters in our high school. nothing
makes you feel more like a hacker than punching some numbers on a calculator
while all your friends watch, and bam, you're browsing forbidden websites
while they all say "whoaa!"

~~~
justinwr
Same thing happened to me in 1998 but in tech school. Good times. ;)

------
mike-cardwell
[http://help.getpocket.com/customer/portal/articles/1225832-p...](http://help.getpocket.com/customer/portal/articles/1225832-pocket-
security-overview)

"Pocket does not provide monetary compensation for any identified or possible
vulnerability."

Cheapskates. This could have cost them money if somebody abusive had
discovered it first. He deserves a monetary award.

[edit] Should we be concerned about the massive number of people listed on
that page who have found security problems with Pocket? I counted 153 separate
people...

~~~
alimbada
It's a freemium service that doesn't depend on ad revenue. Maybe they're not
made of money as Facebook and Google are and that's the reason for not
compensating.

~~~
mike-cardwell
Here's a picture of their current team:
[https://getpocket.com/jobs](https://getpocket.com/jobs) \- Here's a list of 7
other positions they're currently hiring for -
[https://boards.greenhouse.io/pocket](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.

~~~
balladeer
Not to forget the data they are getting:

1\. What people are reading

2\. What they will read

3\. What they have read

4\. What they are just bookmarking/RILing and not reading

5\. Etc etc.

That's valuable data imho.

------
skarap
Yet another service discovered which was built/deployed with no regard for
security whatsoever. I'm beginning to realize - this is the norm. Security is
the least important thing for most of the IT companies.

I guess the DevOps trend (i.e. not hiring sysadmins) should take it's share of
blame. Or maybe it's the other way around - you don't care for security, so
there is no point in hiring security experts?

~~~
mmatants
It's hard to get an intuitive feel for security.

If team principals are mostly young and don't have exposure to _very specific_
kind of experiences dealing with threat modelling, then the security work will
always take a backseat to feature-building. It's how humans work - it's hard
to cut time from nice visible things and dedicate it to a hypothetical (at
that point) abstract goal like security. Everyone agrees that the latter is
important, but it just never ends up getting any oxygen. What's worse, if the
team does not know what tightening systems _feels_ like, they don't even know
where to start. No "muscle memory" for it.

Maybe at some point we'll get more baseline collective wisdom about it
throughout the industry, but it will also take the people signing the cheques
(CEO, investors) having a bit more (justified) paranoia and respect for these
priorities, and consequently requiring them from the outset. And DevOps has
little to do with it - security has to be established as a priority from the
leadership levels on down anyway because it necessarily means reducing time
spent on more immediately-visible things.

~~~
skarap
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.

------
BenjaminWill
Oh Mozilla, why couldn't you resist the money. Your recent so called
"services" are not welcome. You know it. But well, money makes the world go
around.

How much did Telefonica pay you for the Hello integration?

But sure, our surfing history will be secure ...

[https://blog.mozilla.org/advancingcontent/2015/05/21/providi...](https://blog.mozilla.org/advancingcontent/2015/05/21/providing-
a-valuable-platform-for-advertisers-content-publishers-and-users/)

Did you guys acutally read your PR-bullshit here?

But soon a new small, fast, free, secure open-source browser will arrive and
Mozilla will be history. But your pocket full. Well done.

~~~
callahad
When we decided to add a reading list to Firefox, we had two options: build
and maintain our own service and integrations, or partner with an established
player who had sane privacy and data access policies. We chose the latter.

Pocket began life as a Firefox add-on, and is now integrated into literally
hundreds of applications. Embracing that is a reasonable choice in terms of
sustainability and value for users.

For what it's worth, I do not believe any money changed hands in the Pocket
deal, but I don't know that authoritatively.

~~~
nacs
> 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.

~~~
callahad
> _There 's been tons of people asking for the removal of Pocket from Firefox_

That's true. However, we have surveyed large swaths of our users and found
that for all the people that dislike the Pocket integration, several times as
many actively _do_ like it. They're not you or me, but barring a significant
sampling error, it means the dissenters are a vocal but small minority. Of
course, both classes are overshadowed by the proportion of users who don't
care one way or another.

> _" oh you can disable it by going to your about:config and finding this key
> and setting it to false"_

That's false. From day one, you could disable Pocket entirely by right
clicking on it and choosing "Remove from Toolbar" or by dragging it off the
toolbar in the customization mode.

~~~
norea-armozel
I'm sorry, but this logic doesn't make much sense when you consider the fact
that it's a third party service which may not be there next quarter or even
next year. How about you just do the right thing and unbundle the extension?
Make it an opt-in by default. Not an opt-out.

~~~
Forlien
I'm confused by your argument that because the service's status may change, it
shouldn't be bundled. Couldn't they update to remove Pocket if the service
goes away? It's not like Firefox is going to stop development anytime soon.

~~~
yeukhon
Pocket is not Facebook. Pocket can go out of business sooner than Facebook
will ever go out of business. Including Pocket can actually promote Pocket to
get more users, so to some Fx users they suspect there was some money-business
deal involved. After all Firefox doesn't bundle Yahoo being the default search
in the North America region without Yahoo paying at least what Google was
paying.

------
cddotdotslash
Really interesting write up! I'm surprised they are still running in
EC2-Classic. However, even if they are, security groups should still be
restrictive enough to prevent some of the things discussed. For example,
bypassing the load balancer shouldn't be possible. A security group applied to
the back end instances should only allow HTTP/S traffic from the load balancer
group. SSH security groups should only allow inbound traffic from known IPs
(like the office network), etc. Unfortunately, not enough people do this, and
once you can query instance meta data or obtain an SSH key, it's game over.

~~~
skarap
> once you can query instance meta data or obtain an SSH key, it's game over

It's usually the _public_ SSH key which is stored in instance metadata. IAM
roles/STS is much more scarier in this case.

------
ddlatham
If you were Pocket how would you handle the vulnerability created by having
internal services hit user-supplied URLs?

Some ideas:

\- Move the service doing the fetching to an untrusted network. At least it
would be unable to access any internal services and any compromises there
would be hopefully limited. You still have the problem that the local machines
there could potentially be compromised.

\- Validate / verify the URL to ensure it's not hitting anything internal.
This sounds hard. Pre-resolve the name and check to see if the IP is in an
internal range? Seems easy to get our of date as your network changes. Make
sure to repeat for any redirects? Is there a better way to validate?

\- Ensure that all internal services require authentication. This also sounds
hard and easy to miss something.

~~~
option_greek
Regarding point 2 (Validate), won't blocking the entire private address IPV4
range (10.xx, 172.xx, 169.xx, 127.xx and what not) suffice ?

~~~
pfg
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](https://news.ycombinator.com/item?id=10079554)

------
pdkl95
This is the problem with services that store user information: it is highly
probably that vulnerabilities like these exist. Security is rarely given the
time and attention it requires.

I'm not trying to single out Pocket; they are just the latest evidence that
even in the few cases where "you can trust us with your data" is said
honestly, it isn't a promise that can be kept in practice.

------
falcolas
One more vulnerability which is possible when you can request an instance's
metadata: Any AMI roles which have been given to that instance (for example to
enable S3 access or decrypt data using AWS' key service) would be visible.

These keys are rotated relatively frequently, but it opens up a whole new
level of exploits against the company which runs those AWS servers.

------
schmichael
Is there a name for this sort of attack? We were just protecting against some
similar attacks earlier this week, and it would have been nice to have a short
name to refer to them as instead of "that attack vector where we make
unrestricted HTTP requests based on user input".

~~~
Manishearth
"Server Side Request Forgery" (SSRF)

------
mrbig4545
running as root??? seriously?????

~~~
falcolas
Most developers don't think (or know) about security issues like this, and
running something as root avoids a whole class of deploy problems, so I
understand why this can happen.

It's certainly not right, and indicative of the need for either a system
administrator with an eye for deployment best practices, or an explicit
security position who sets up audits to look for these kinds of flaws.

~~~
mahouse
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

~~~
acdha
This was a stronger argument in the past when multi-user/app systems were the
rule. If you have only one app running on a box and it can access all of the
data which matters, what precisely does getting root give you which getting
that app user does not?

Yes, someone could install a rootkit but these days the way to deal with a
compromise is to replace the entire system and in either case it's most likely
that that process would be initiated by some external clue.

(edit: to be clear, I still don't deploy as root but that's more for other
reasons like isolation and I'd be surprised if that was the most pressing
security concern on many sites as opposed to things like insecure local
services, overly-broad, chainable credentials, etc.)

~~~
detaro
The ability to go around the host firewall. Accessing data from sub-services
that otherwise might run isolated under their own users. The ability to change
application source code. Not applicable in all cases, but probably often
enough.

~~~
acdha
My point wasn't that those aren't good but that they're hard enough to do
effectively that most places won't see much benefit until they've done a bunch
of other things first.

e.g. how many places use least-privilege auth credentials vs. having something
like AWS keys or shared database credentials which have access to a ton of
shared resources? I'd want to compartmentalize something like that well before
changing the UID which code runs under since it's available without any
further exploits.

------
billyhoffman
I'm really not a fan of EC2 exposing instance meta data as a RESTful HTTP API
running on Local-Link IP addresses. If its only supposed to be queried
locally, why aren't these just environment variables? Perhaps they are dynamic
and that won't work but come on!

At the very least, run it on localhost:10101 or something. Don't give us
another range to have to filter!

~~~
skarap
One of the biggest selling points of EC2 (at least for me) is that you get a
real VM with a real kernel and userspace, and not some "user-friendly" thing
the provider made with loads of alien services running as root. So EC2 can't
define vars inside your instances + as you said, they can be dynamic.

localhost:SOMETHING will also not work for same reason - they would need to
run a service inside your instance.

There is one more popular solution to the metadata problem - providing it as
an emulated cdrom, which would be also vulnerable in this case. And it can't
be dynamic.

------
robn_fastmail
If you want a laundry list of SSRF methods you should protect against, a great
place to start is this slide deck from a talk at ONsec a couple of years ago:

[http://www.slideshare.net/d0znpp/ssrf-attacks-and-sockets-
sm...](http://www.slideshare.net/d0znpp/ssrf-attacks-and-sockets-smorgasbord-
of-vulnerabilities)

Its thrilling and terrifying :)

------
hundt
Security researchers out there: on what side of "the line" do you view this
kind of exploitation to be? It was not done for nefarious purposes, but it did
involve intentionally accessing resources that were clearly not intended to be
accessed, like /etc/passwd. Would you worry if you did this that the company
might call the police instead of thanking you?

------
halosghost
The one thing I don't like about this article (and indeed, much of the
discourse around the Pocket integration) is its characterization of the Pocket
integration itself. It calls it an “opt-out non-removable [extension]”. The
truth is that you can easily disable it just as you can easily disable many
other things that Firefox includes by-default. In fact, if you use Classic
Theme Restorer (I use it not because I dislike australis, but because I really
do not want a navigation toolbar), it has an option baked in to disable Pocket
along with webrtc, et al.

Admittedly, I suppose it would be nice if Firefox actually packaged Pocket as
a real extension that could be removed from the Extensions menu, but they have
already integrated several things without using that schema.

I still use firefox, just with more and more things disabled, because none of
the other browsers out there even come close to having what I need in a GUI
browser (though, I would note that I'm evermore tempted to abandon GUI
browsing altogether).

Either way, the write-up is great, and everything in the article other than
that one characterization (which rubbed me a bit the wrong way in the wake of
all the fevered discussions around the Pocket Integration) was a truly
enjoyable read. Not to mention, it's great that the Pocket devs fixed things
quickly; that's always a plus!

~~~
sigmar
>you can easily disable it just as you can easily disable many other things
that Firefox includes by-default

>it would be nice if Firefox actually packaged Pocket as a real extension that
could be removed from the Extensions menu

These two statements you made seem to corroborate his characterization of it
being "opt-out" (meaning on by default, but capable of being disabled) and
"non-removable" (baked into firefox as opposed to an extension). Not sure what
you find wrong with his characterization.

~~~
halosghost
“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.

~~~
sigmar
Ah, okay. I understand your position better now. Thanks for the reply.

~~~
halosghost
Happy to do it. The last thing I want is for my post to have come across as
vitriolic or argumentative; I just wanted to voice the one case of unease the
article left me with :)

------
luxoria
>Grab ssh private keys from autoprovisioned EC2 user’s home directory using
301 redirect to file URI (after all, we’re running as root, we can read them).

This is not a fair assumption to make. Maybe they are running a LSM like
AppArmor.

~~~
skarap
What is more important - the existence of SSH _private_ keys on the EC2
instances us unlikely... There is chance there are SSH private keys there, but
they would most probably be SSH deploy keys for some private repo
(configuration management, software).

------
_navaneethan
You should receive some _gift_ from pocket team :)

------
Iuz
Is it ironic that I saved the article on pocket?

------
dafrankenstein2
i prefer using offline bookmark..specially the bookmark manager of Opera
browser is impressive. ============================================= and for
online bookmarking there is 'raindrop.io'

