Google and Mozilla Push for AV1 Image Format Adoption, Beats JPEG and HEIC

[bug]

Oops Sorry you need to brush up on a few things
if image is loaded or Data into a Browser then the Browser runs the data
Or Do You Dispute that this can Happen ?
Remember the Crypto Coin Mining Browser Contraversity currently Circulating

When a browser loads an image, it will never, under any circumstances need to execute that part of the memory. It knows it's data, therefore it does not need to be executed. It's why we have languages like Rust and DEP at a hardware level: to make sure data memory regions are not "executed".

And let's leave mining out of this, it really has nothing to do with the subject.

There a lot of way to to run an code from within a a file that has the signature of an image (or pretty much everything else) by exploiting the vulnerabilities of the software used to view them. One of the most basic methods is screwing with buffers and overwriting data at locations in memory that are marked as being executable. That's how code gets to "run by itself by simply loading it into memory" , it ain't that complicated.

View attachment 96277

Thank you, this is what I've been saying from the start: it's the decoders that should be under scrutiny here, not the image format itself.

 

[Sasqui]

PNG is more the newer GIF and JPEG 2000 was too complex and had patent issues.

That does remind me of the patent issues with GIF files. Compuserve owned the rights to GIF, and if you inadvertently stuck a GIF into commercial software, there was a chance they'd come knocking at your door for license $. The patents have long expired on GIF at least, about 10 years ago. For pictures with not too many colors, like windows dialogs and icons, it was a very efficient compression format, certainly compared with .BMP and as far as I know, GIF was lossless.

JPEG is extremely lossy, but flexible and pretty efficient. I'm curious how this compares.

 

[_UV_]

Sure, old inefficient JPG is our main problem!

Download current page (save complete to your disk), according to my word processor main article + some comments = 15600 symbols and spaces, ok Unicode is double byte and add little extra html and we got 71 kilobytes. Now lets see to supplemental folder for our nice HTML: 52k of images and 939k of CSS/JS/BS... 1 Mbyte per 20 paragraphs of text and 5 simple ad pictures.

And youtube...

Sure JPG is old and consumes so much traffic...

 

[Exceededgoku]

^^ this guy speaks the truth!

 

[bug]

^^ this guy speaks the truth!

He does, but image compression is not only about the size of a web page.
The web is a separate mess

 

[trparky]

When a browser loads an image, it will never, under any circumstances need to execute that part of the memory. It knows it's data, therefore it does not need to be executed. It's why we have languages like Rust and DEP at a hardware level: to make sure data memory regions are not "executed".

Yes but a lot of stuff is still written in old C/C++ in which if you mess up you tend to mess up quite badly. All it takes is someone to not put in proper bounds checking code and oops, malicious code is spilled out and onto the stack and before you can say "Oh crap" your system is p0wned.

 

[bug]

Yes but a lot of stuff is still written in old C/C++ in which if you mess up you tend to mess up quite badly. All it takes is someone to not put in proper bounds checking code and oops, malicious code is spilled out and onto the stack and before you can say "Oh crap" your system is p0wned.

Again, it's in the code, not in the image.
If you people can't tell the difference, I give up. Because I just don't know how to explain it any better.

Edit: Usually if you do not "put in proper bounds checking code" your program will simply segfault and crash. It takes a highly skilled/calculated overflow to provoke an intentional execution outside your designated address space.

 

[trparky]

That depends upon what you consider an "image". Do you consider an image just the picture data payload or the picture data payload and the metadata that goes along with it? If someone were to put some data into the metadata portion of the image and include malicious code as part of the metadata and the parser of said metadata had an exploit in which it wasn't checking the bounds properly and thus blindly shoved that data into a buffer without checking the length of it then yes, you can exploit it.

 

[bug]

I'm just going to say you're just being stubborn. Because I refuse to believe you're that dumb.

The image may contain the code to remove all the internet from existence; it doesn't matter. The image cannot execute that code. There needs to be another party that points to that code and commands its execution.

 

[trparky]

Well then tell me why taking Internet Explorer onto the modern Internet is like walking into a less than desirable brothel and walking out with a bunch of STDs? Because all it takes is something to exploit the image rendering engine and boom, you're done son. Internet Explorer has tons of these exploits. You should read some of the security write-ups on Internet Explorer, you'd never sleep at night. The same goes for Google Chrome which at least the thing is sandboxed so if it were exploited at least the damage is contained.

 

[R-T-B]

Jesus Christ , an image loaded into memory can contain without doubt code which can then execute on it's own. Just like pretty much everything else.

No, code doesn't just execute on it's own, especially not data formats.

Bug is right. There was an exploit in the XP image handler (and it was REALLY misdesigned) way back when but there has not been one in a very very long time since.

PS: I'm actually a programmer.

Well then tell me why taking Internet Explorer onto the modern Internet is like walking into a less than desirable brothel and walking out with a bunch of STDs?

Nothing to do with the image handler, I assure you. Everything to do with it's millions of ways it can be exploited due to be an insecure browser (think javascript).

 

[dorsetknob]

No one has really said the potential image payload will run itself just that the image can contain an additional data payload and that can have nasty consequence's

 

[trparky]

There was an exploit in the XP image handler (and it was REALLY misdesigned) way back when but there has not been one in a very very long time since.

Ah yes, the old Windows Metafile (WMF) Image exploit. Who could forget that badly designed format? It was an exploit just waiting to happen.

 

[bug]

Well then tell me why taking Internet Explorer onto the modern Internet is like walking into a less than desirable brothel and walking out with a bunch of STDs? Because all it takes is something to exploit the image rendering engine and boom, you're done son. Internet Explorer has tons of these exploits. You should read some of the security write-ups on Internet Explorer, you'd never sleep at night. The same goes for Google Chrome which at least the thing is sandboxed so if it were exploited at least the damage is contained.

Because IE itself is full of holes and used to be rooted into the Windows kernel. Find a way to execute random code in IE and chances are you don't need elevated privileges, you're already an admin.
Yet again, nothing to do with image formats.

Edit: @dorsetknob instead of liking @trparky 's every post just because he agrees with you, do yourself a favor and read about these things. I guarantee it won't be time wasted.

 

[dorsetknob]

You fail to acknowledge that image files have in the past have been used as an attack vector. this is a
new image file format and there does exist the potential for malicious payload to be embedded.
Someone or some Agency is or will consider exploring that potential. ( its not unfounded Speculation But unfortunatly a reasonable Expectation)
Who knows (probably the 5 eyes and friends) what exploits are out there in various O/S waiting for hidden payload(s) to exploit

And finally A Sarcastic thanks for suggesting how my like/thanks should be Post awarded

 

[trparky]

@bug

PNG Embedded – Malicious payload hidden in a PNG file
ImageTragick
Adobe Photoshop CS6 - '.png' Parsing Heap Overflow
MS15-024: Vulnerability in PNG processing could allow information disclosure: March 10, 2015
PNG Shortcut Silent Exploit
Beware! You Can Get Hacked Just by Opening a 'JPEG 2000' Image
Stegosploit: Owned by a JPG

Need I go on? Those are all exploits that can get you just by opening a seemingly innocent image file.

What's that sound? Oh yeah... that's the sound of me p0wning you.

 

[dorsetknob]

Need I go on? Those are all exploits that can get you just by opening a seemingly innocent image file.

And i will just chuck this in here
Apple O/S Attack Vector just found
Other noteworthy bugs include CVE-2018-4094, a bug in both Sierra and High Sierra discovered by five researchers at Yonsei University in Seoul, South Korea. The memory corruption bug allows remote code execution attacks simply by processing a maliciously crafted audio file.

What's that sound? Oh yeah... that's the sound of me p0wning you.

 

[Aquinus]

@bug

PNG Embedded – Malicious payload hidden in a PNG file
ImageTragick
Adobe Photoshop CS6 - '.png' Parsing Heap Overflow
MS15-024: Vulnerability in PNG processing could allow information disclosure: March 10, 2015
PNG Shortcut Silent Exploit
Beware! You Can Get Hacked Just by Opening a 'JPEG 2000' Image
Stegosploit: Owned by a JPG

Need I go on? Those are all exploits that can get you just by opening a seemingly innocent image file.

What's that sound? Oh yeah... that's the sound of me p0wning you.

Jesus christ. You didn't pwn anyone. You proved exactly what was said earlier: It depends on the implementation of the image handler.

Thank you, this is what I've been saying from the start: it's the decoders that should be under scrutiny here, not the image format itself.

Image formats aren't inherently dangerous but, an application not ensuring that the image is actually legit is the problem. It's not a problem with the file format. It's a problem with how the handler (in that case mind you,) processes the image. Blaming image formats for being a target for remote code injection is about as stupid as blaming SQL because applications can't sanitize inputs to prevent SQL injection. Sure, shame on the developer for not catching it but, it has nothing to do with the image formats.

Any poorly written decoder, regardless of data being provided, can be a security hole... and honestly, if you're using something like ImageMagick, you would be getting exactly what you deserve because, it's trash.

 

[bug]

Jesus christ. You didn't pwn anyone. You proved exactly what was said earlier: It depends on the implementation of the image handler.


Image formats aren't inherently dangerous but, an application not ensuring that the image is actually legit is the problem. It's not a problem with the file format. It's a problem with how the handler (in that case mind you,) processes the image. Blaming image formats for being a target for remote code injection is about as stupid as blaming SQL because applications can't sanitize inputs to prevent SQL injection. Sure, shame on the developer for not catching it but, it has nothing to do with the image formats.

Any poorly written decoder, regardless of data being provided, can be a security hole... and honestly, if you're using something like ImageMagick, you would be getting exactly what you deserve because, it's trash.

Thanks. I was beginning to wonder if English not being my mother tongue is the problem here.

 

[Aquinus]

Thanks. I was beginning to wonder if English not being my mother tongue is the problem here.

People seem to not understand the difference between a data format and a tool that reads said data format. I don't think this is a language barrier but, rather a misunderstanding of what is responsible for what. Data formats really can't be dangerous, it's how they're used that can be. If a tool doesn't want to do proper validation and sanitation, that's on them.

 

[trparky]

Who the heck said that I was talking about the image format itself? Someone is putting words in my mouth and I don't like it!

I am fully aware that there is a difference between the image format the rendering engines that take said image formats and convert them into something us humans can see on our screens. Like, DUH! I'm just pointing out that there have been multiple occasions where someone got something very wrong while parsing said file and it ended up doing something bad. I tend to read the security bulletins when patches are released because, well... just because. Some of them really have sent my palm to my forehead while saying "How the hell did they mess this one up?" to myself.

As for ImageMagick, you do know that ImageMagick is module that is often used on servers combined with PHP to process image uploads. Right? Heck, this site right here probably uses ImageMagick on the backend to resize images. All it would take is someone to upload a malicious image file and the server on which this site is running would be exploited.

 

[bug]

Security Features ? or will we have to expect sooner or later for this format to be compromised with embedded nastily as Some Current formats "Can BE".

Who the heck said that I was talking about the image format itself? Someone is putting words in my mouth and I don't like it!

In that case, maybe you should read the statement you're backing up more carefully?

 

[smillien62]

I will be happy when ImageMagick and Java ImageIO can handle this new image format av1.

 

[Prima.Vera]

I love PNG for its looseless quality, but the image size is kinda too big. And the majority of cameras and phones do not support it.