Live data from Hacker News

This JPEG is also a webpage

lcamtuf.coredump.cx

61–70 of 236 posts

Re: This JPEG is also a webpage

#61
post #15

Earlier quoted context omitted.

No, because if parsed as a JPEG, arbitrary code wont be run. If the jpeg was somehow parsed as JS, then possibly yes.

The image reference tag is for an image. As stated previously, if you look at the JPEG itself, it starts off with a JPEG comment, which embeds the entire html block, then starts a comment block for the remainder of the JPEG data. Browsers are very liberal in what they accept, so that initial 20-byte header is ignored, although you can see it if you inspect the page's elements.

Yes, I get that - but if a tracking pixel is downloaded and interpreted as a jpeg, then it will parse anything in the COM section as a comment, and not execute anything in it, unless there was some sort of vulnerability in the JPEG implementation

Re: This JPEG is also a webpage

#63
post #52

> Pretty radical, eh? Send money to: lcamtuf@coredump.cx How to send money to your email address? Not that I would send you some, but I wondered how you want to have that money received?

1. Most Gmail users can receive money by email ( https://support.google.com/mail/answer/3141103 and coredump.cx MX records point to Gmail) 2. Ask him his Bitcoin address 3. Paypal to this address :)

Isn't Google Wallet ded?

Re: This JPEG is also a webpage

#66
post #42

Right-clicking on the image and selecting "View Image" (Firefox), or "Open image in a new tab" (Chromium), gives the webpage, not the image. I can see why that happens: the menu items just open a URL and don't force it to be an image. However, it was a bit disorienting.

I did this too, repeatedly, until I was smiling a very big smile.

Re: This JPEG is also a webpage

#67
post #35

Earlier quoted context omitted.

Or one of the best. Switch wen browsers to strict processong and you will hardly find working web page.

Yeah, imagine if processors gave best effort to processing binaries... what could possibly go wrong :/ The decision to allow this was made early and the liberal accept/strict transmit paradigm has in general made the web a mess. On the plus side, the consistent failure of browser vendors to apply strict controls to input means that as an application security person I will probably never be out of work :D Even though…

> as an application security person I will probably never be out of work

How many security flaws are the result of malformed HTML?

Re: This JPEG is also a webpage

#68
post #27

A testament to one of the worst decisions in computing history - not to fail displaying a web page with an error message in case it is not a valid HTML document.

Being flexible about what markup is accepted has meant the web could gain new features and gracefully degrade, and has made it more fault-tolerant. It's not at all a failing. Compare that to JavaScript, which will happily fail if you use new syntax or a missing function, and thus web pages which rely on JS often show up as just a full screen of white when something goes wrong, which it frequently does. That's not to…

A parser could always just ignore tags it does not recognize, no need to try to make sense of any random collection of tags.

Re: This JPEG is also a webpage

#69
post #5

great hack, could you get javascript working inside a jpeg as well? Or obfuscate the javascript and decrypt in the browser for steganographic purposes?

No, the JPEG header is at the start of the file, unlike the PNG which is at the bottom.

Pardon my ignorance, but what does that matter?

There's an important note in that the HTML is not at the true start of the JPEG file, it's slightly after. You can even view some of the JPEG format bytes if you view source of the HTML.

So if the browser ignores some of the JPEG file, why not most of the PNG file? Perhaps you run the risk of some random byte screwing up the HTML though.. not sure.

Re: This JPEG is also a webpage

#70

This site uses the xmp tag (deprecated in HTML 3.2, removed in HTML5) which I found interesting and had never seen! https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xm... It's similar to the pre tag but doesn't require the escaping. I guess you just have to make sure you don't have a closing xmp tag :)

is great when you absolutely, positively, do not want any entities rendered under any circumstances. It's unfortunate that it's being deprecated, since it has its uses.
Post reply on HN