Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

51–60 of 197 posts

Re: How we got read access on Google’s production servers

#51
post #5

Interesting to see this hit big companies like google. The problem, I think, stems from the idea that most people treat XML parsers as a "black box" and don't enquire too closely as to all the functionality that they support. Reading the spec. which led to the implementations, can often reveal interesting things, like support for external entities..

I agree, this can be summarised as "abstraction hides bugs". I believe that although abstraction is a powerful tool, there is such a thing as too much of it, and when reading an XML document can cause access to other files, maybe even across the network, perhaps things have gone a little too far. This isn't like an obvious #include or @import, it's much more subtle.

When I first noticed that HTML doctypes have URLs in them, I inquisitively tried accessing them, and it brought up a lot of questions in my mind about why it was designed that way, what would happen if the URLs no longer existed, etc. Such an explicit external dependency just didn't feel right to me. Unfortunately most people either don't notice or seem to ignore these things...

Interestingly enough, not all XML parsers support external entities; the first one to come to mind is this: http://tibleiz.net/asm-xml/introduction.html

Re: How we got read access on Google’s production servers

#52
post #14
post #4

XML legitimately scares me. The number of scary, twisted things it can do make me shudder every time I write code to parse some XML from anywhere - it just feels like a giant timebomb waiting to happen.

> every time I write code to parse some XML Why would you write code to parse XML? Use an existing parser to parse. Use XSLT to modify/transform (including generate JSON/CSV/other).

Okay, parent comment obviously came out wrong and is starting its descent into white hell... ;-) I'm not going to delete it since it would be unfair to the child comments.

XML is for some reason a super-controversial technology that is apparently almost universally hated, and XSLT even more so. I hope I'll not be downvoted even more by asking what's scary about being downstream from a (serious, well-maintained) XML parser?

(And I love XSLT. What can I say.)

Re: How we got read access on Google’s production servers

#53
post #19
post #6

Earlier quoted context omitted.

Also horrible defaults in XML parsers. That any XML parsers allow retrieval of DTD's without explicit options specifying allowed sources etc. is beyond me. It's not just local file access, which becomes a security hole when you let users pass you XML files, though that is one of the worst ones. But the number of times I've seen production apps that turn out to behind the scenes request DTD's or schemas from remote se…

It's bad practice to fetch an external DTD on a server you don't control, first for security reasons, second because your application then depends on something that can go away anytime, third because it's rude to the third party. twic is right that one should always use entity resolvers that point to local ressources and that parsers should run in a sandbox without external access. He's also right to say that by defa…

It is bad practise but you know that it is uncannily common?

Just remember that the W3C had to impose download restrictions on the (X)HTML DTDs (http://www.w3.org/Help/Webmaster#block)

Re: How we got read access on Google’s production servers

#54

Earlier quoted context omitted.

Bitcoin would be the preferable way to get payed in this situation.

How would you escrow it so that you can be sure to actually get the funds? Sure they're not going to pay up front and it would be over-trusting to give a crack away on the promise of later funds, so ...

That's not really a problem specific to Bitcoin only. I've seen Bitcoin Escrow services but I'm not sure which ones are trust worthy.

Re: How we got read access on Google’s production servers

#55
post #15

Just $10k? This sells for at least 10 times more on the black market. Why would one rationally chose to "sell" this to google instead of the black market. Some people don't break the law because they are afraid to get caught, but I like to believe that most people don't break the law because of the moral aspect. To me at least, selling this on the black market poses no moral questions, so, leaving aside "I'm afraid t…

You have a very strange sense of morality, IMO. I refrain to inflict damage to others for personal gain, it's really that simple to me. Other questions are complicated and conflicting, but this is quite clear cut to me.

Re: How we got read access on Google’s production servers

#56

This is another reason not to use XML, plain and simple It's too much hidden power in the hands of those who don't know what they're doing (loading external entities pointed in an XML automatically? what kind of joke is that?)

Sure, but didn't YAML in Rails do mostly the same type of thing? It's not just XML that is dumb like this.

Re: How we got read access on Google’s production servers

#58
post #52
post #14

Earlier quoted context omitted.

> every time I write code to parse some XML Why would you write code to parse XML? Use an existing parser to parse. Use XSLT to modify/transform (including generate JSON/CSV/other).

Okay, parent comment obviously came out wrong and is starting its descent into white hell... ;-) I'm not going to delete it since it would be unfair to the child comments. XML is for some reason a super-controversial technology that is apparently almost universally hated, and XSLT even more so. I hope I'll not be downvoted even more by asking what's scary about being downstream from a (serious, well-maintained) XML p…

What's "scary" (not the term I would personally use) is that the libraries typically aren't safe by default against malicious use. Users of the library have to know a lot in order to make them safe. See https://bitbucket.org/tiran/defusedxml for some of the potentially nasty gotchas in XML and XML-related technologies. Quoting from it:

> None of the issues is new. They have been known for a long time. Billion laughs was first reported in 2003. Nevertheless some XML libraries and applications are still vulnerable and even heavy users of XML are surprised by these features. It's hard to say whom to blame for the situation. It's too short sighted to shift all blame on XML parsers and XML libraries for using insecure default settings. After all they properly implement XML specifications. Application developers must not rely that a library is always configured for security and potential harmful data by default.

Re: How we got read access on Google’s production servers

#59
post #39
post #22

Earlier quoted context omitted.

[...] why would one not sell this on the black market? Because it is wrong to harm others for personal benefit?

I agree with you however companies are completely the void of morality their only purpose is profit and they will hire shady lawyers to interpret the law in their favor fire people without giving it a second thought or collude with other big companies to keep their employees wages low so why would i treat them differently. In business morality is a luxury that some companies can't afford and most choose not to have s…

companies are completely the void of morality their only purpose is profit

Companies are groups of people and have many different purposes. I understand being worried about the rise in corporate oligarchy, but your argument is itself the attitude you are accusing companies of. The problem isn't companies being immoral, but people rationalising behaviour that they know to be immoral.

Re: How we got read access on Google’s production servers

#60

This is another reason not to use XML, plain and simple It's too much hidden power in the hands of those who don't know what they're doing (loading external entities pointed in an XML automatically? what kind of joke is that?)

scnr

    XML - It seemed like a good idea at the time
Post reply on HN