Seems Legit

[menotu]

Here's a clip from a US TV show called "Bones".

In it, a computer virus crashes a computer. And sets it on fire. The virus got in via a fractal. Embedded on a bone of a shooting victim.

Seems Legit.

http://www.f-secure.com/weblog/archives/00002307.html

http://www.liveleak.com/view?i=e27_1327440153

[Neal ManBear]

I enjoy watching Bones.      

[Just18]

I enjoy watching Bones.      

+1

......  and that was inventive 

[The Chief]

But not very realistic.  A fractal is an image drawn by multiple executions of a mathematical algorithm.  The image, one produced, is no different than any other image. 

Scanning or viewing the image cannot possibly insert a virus.   Code is code, data is data, and never the twain shell meet.

And what possible software algorithm could set a computer ablaze?

[AS]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

[pags]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Yeah, well, code is just a type of data (it's all ones and zeroes)...

But getting in infection in via this method (how was the fractal put on the bone?) should really be highlighting a security issue with the scanning software
 

[The Chief]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Maybe - don't know much about SQL, other than, basically, what it is. 

But it all depends on how the program looks at it.  If it is expecting data, you can feed it all the code you want, and it will never try to execute it.  You may get results that are not what you expect, but bad data is still just data.

[pags]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Maybe - don't know much about SQL, other than, basically, what it is. 

But it all depends on how the program looks at it.  If it is expecting data, you can feed it all the code you want, and it will never try to execute it.  You may get results that are not what you expect, but bad data is still just data.

Depends on what the application does with the "data".  If this were a unilaterally true statement, there wouldn't be MS Office macro viruses...
 

[Crow]

Is worth just to see Michaela Conlin   

[Rudge]

Come on,, the software that would have been used to scan those bones would have no business converting images to text. That would have been the first required step. (and that's assuming any software that was already installed on the computer could even read and decipher the text that would have been written on a bone)

Then on top of that, "something" would have had to initiate the process of saving the code (text file) separately as an executable and then executing said file.

As someone that understands the process as little as I do, the clip was still painful to watch as I know, there are people in the wild, that believe this can happen.      

edit: I won't comment on the fire as I have seen bad code physically destroy a printer once.   

[Neal ManBear]

Is worth just to see Michaela Conlin   

     
       

[The Chief]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Maybe - don't know much about SQL, other than, basically, what it is. 

But it all depends on how the program looks at it.  If it is expecting data, you can feed it all the code you want, and it will never try to execute it.  You may get results that are not what you expect, but bad data is still just data.

Depends on what the application does with the "data".  If this were a unilaterally true statement, there wouldn't be MS Office macro viruses...
 

I did say if it is 'expecting' data.  I suppose the macro processor is expecting code, so in that case it may be possible to insert a virus - if you allow an unknown external macro into the system. 

A properly written macro processor would warn you of an external macro before executing it. Or at least would not allow any macro execution not initiated by the user.

But it would never happen from a scanned image...

[pags]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Maybe - don't know much about SQL, other than, basically, what it is. 

But it all depends on how the program looks at it.  If it is expecting data, you can feed it all the code you want, and it will never try to execute it.  You may get results that are not what you expect, but bad data is still just data.

Depends on what the application does with the "data".  If this were a unilaterally true statement, there wouldn't be MS Office macro viruses...
 

I did say if it is 'expecting' data.  I suppose the macro processor is expecting code, so in that case it may be possible to insert a virus - if you allow an unknown external macro into the system. 

A properly written macro processor would warn you of an external macro before executing it. Or at least would not allow any macro execution not initiated by the user.

But it would never happen from a scanned image...

http://www.tgdaily.com/security-features/51056-embedded-malware-hidden-in-image-files

Also, there is steganography.

While I still suspect that what is portrayed (as it is portrayed) in this episode of Bones is not likely at this time, I would never rule out the future possibilities...
 

I would also still fault the system, and not the breach attempt, as the weak link.

[ElCuervo]

Is worth just to see Michaela Conlin   

+1 - they could tell me anything as long as they let me look at her!

[The Chief]

Code is code, data is data, and never the twain shell meet.

Agreed, but ... what about "SQL Injections" ?  Aren't based on mixing code and data ?

Maybe - don't know much about SQL, other than, basically, what it is. 

But it all depends on how the program looks at it.  If it is expecting data, you can feed it all the code you want, and it will never try to execute it.  You may get results that are not what you expect, but bad data is still just data.

Depends on what the application does with the "data".  If this were a unilaterally true statement, there wouldn't be MS Office macro viruses...
 

I did say if it is 'expecting' data.  I suppose the macro processor is expecting code, so in that case it may be possible to insert a virus - if you allow an unknown external macro into the system. 

A properly written macro processor would warn you of an external macro before executing it. Or at least would not allow any macro execution not initiated by the user.

But it would never happen from a scanned image...

http://www.tgdaily.com/security-features/51056-embedded-malware-hidden-in-image-files

Also, there is steganography.

While I still suspect that what is portrayed (as it is portrayed) in this episode of Bones is not likely at this time, I would never rule out the future possibilities...
 

I would also still fault the system, and not the breach attempt, as the weak link.

The first case requires active user intervention.  That's not a virus, it's a con-job.  Save it as a .bmp?  OK - then what?  Who tries to run a .bmp?  And even if you did, the OS should recognize it as a .bmp and merely try to display the 'fuzziness,' as best it can.

The second case, it's all data, just that some is hidden in a different kind of data.  How would you execute it?