Not too far-off from the oft-mocked segment in Bones where a computer is infected by making an MRI scan of a malware fractal pattern embedded in the bones.
Even though in this case the software vulnerability was introduced by the researchers, this is still a very innovative proof of concept that combines techniques from biochemistry and computer security.
They modified an analysis program so that it uses a fixed-size buffer in a vulnerable way (no bounds checks, etc). Then, they synthesized some DNA that, when sequenced and analyzed with this program, overflows that buffer.
To their credit, parts of the paper are very upfront about this, but it's still very hokey, in my opinion. All the DNA stuff feels like a smokescreen around a pretty boring buffer overflow exploit that wasn't even present in the original code.
You don't need to modify existing analysis programs. I worked on a Cloud Genomics product and we inspected BAM parsers, etc, and they all lack basic validation, so it's trivial to create malicious inputs that cause them to crash.
When we filed bugs against the products, the reply was that security was not a priority, because academics.
These kinds of parsers often run on machines that have a great deal of valuable intellectual property on them. It's not unreasonable to believe that somebody might exfiltrate IP from a biotech using malicious DNA sequences. It's unlikely, but not unreasonable to believe.
No such thing as "intellectual property". And it's not like the original program would disappear anyway so I can't see the issue in that specific case.
I'm not sure that is obvious because as a lay-Biologist the input data is just strings of ... um 2-bit ? symbols with no known encoding format (we haven't discovered the "JPEG" of DNA yet). Is quite surprising to me that anyone could screw up parsing that kind of data such that the process could be taken over.
Now if DNA contained an encoded turing-complete language that the lab ends up executing...
But I think we're some way off from achieving that.
The issue is that they forced a buffer to overflow--they put N bytes of data into a bucket that was can only hold n bytes. The extra N-n bytes were carefully chosen so that they would do something "interesting" when they spill out of the bucket and into the program's code (there are ways of avoiding this, like the No-eXcecute bit, which I guess were ignored/turned off for this demo).
In some ways, this is easier to do with unstructured data. If there was some specific format, the overflowed data would have to fit into that format AND do something malicious.
1. The DNA is sequenced.
2. Sequence data are compressed with a version of fqzcomp which has been modified to use/overflow a static buffer.
3. Something about this particular DNA sequence overflows a buffer in fqzcomp
4. The overflow contains some kind of exploit.
The paper is a little vague about where they inserted the exploit into fzcomp(https://fqzcomp.sourceforge.io/), but it does process the DNA sequence a block at a time. It tracks the frequency distribution of nucleotides so it can model them for compression. I hope the exploit was something really clever, like finding a DNA sequence that puts the encoder in a weird state, but it's also possible they just set BLK_SIZE to 1 or something like that.
This is (yet) another buffer overflow exploit. Writing your code in a safe language makes buffer overflows obsolete. This problem was solved a long time ago. It should have been obsolete by now.
Even with code written in unsafe languages, ASLR and the XD/NX bit makes this class of exploits almost completely obsolete. I'm assuming the DNA software they were using had neither turned on.
I'm a bit exhausted of hearing about buffer overflow exploits. There's nothing smart or clever about them (anymore).
Wait what? “Code with security bugs is subject to malware” is not news. The only interesting bit of this headline would be an existing bug in DNA-reading code.
I don't think -- an example off the top of my head, don't nitpick please -- that Clojure and Erlang/Elixir are that easily exploited with buffer overflows. I'd even say they are immune but I am not a security researcher.
As long as the code is "just" malicious to computers.
I dread (but am already certain it will eventually happen) the day when some kind of gene therapy cure will be customized to your DNA and will contain some absolutely nasty bio-DRM (think turbo cancer) if it gets applied to the wrong person, or past a date, etc.
Can we slow down the hate-train for a second...as a relative security newbie, isn't this still a big deal? Isn't all malicious code is written to exploit known (or likely) vulnerabilities in software? Wasn't the point being demonstrated "you can write interpretable code on DNA that can be run on computers, which turns out, can be malicious code too"?
I guess if it was already well-established that reading programmable DNA was a thing, then this is about as innovative as "you can put malicious programs on flash drives, or as email attachments."
But in that case, what would they have to do that's interesting from a biotech+compsci perspective to show impressive work? Have DNA that can find security vulnerabilities on its own? Or somehow create a stack that can use a program on a DNA strand to then attack some more well-known, real security vulnerability? That seems about the same as just running code from DNA, which is what they demonstrated?
But if most people aren't aware of DNA programming, isn't this still cool? Am I missing something else?
I think the big thing this shows is that "Never trust your input data without validation" really means "never" even if the data is something seemingly difficult to tamper with.
This is almost the plot of a scifi novel published in 1994, The Deus Machine, by Pierre Ouellette. The malicious code was placed in introns by nature itself.
"Ghost in the Shell" reality comes closer and closer.
Especially the part when in the original movie two garbage truck drivers were remotely hacked and their identities were completely replaced. That could probably happen by checking out a certain street sign.
37 comments
[ 6.4 ms ] story [ 73.0 ms ] thread> "Bones": The Crack in the Code http://www.imdb.com/title/tt2076424/synopsis
They modified an analysis program so that it uses a fixed-size buffer in a vulnerable way (no bounds checks, etc). Then, they synthesized some DNA that, when sequenced and analyzed with this program, overflows that buffer.
To their credit, parts of the paper are very upfront about this, but it's still very hokey, in my opinion. All the DNA stuff feels like a smokescreen around a pretty boring buffer overflow exploit that wasn't even present in the original code.
When we filed bugs against the products, the reply was that security was not a priority, because academics.
These kinds of parsers often run on machines that have a great deal of valuable intellectual property on them. It's not unreasonable to believe that somebody might exfiltrate IP from a biotech using malicious DNA sequences. It's unlikely, but not unreasonable to believe.
e.g. https://github.com/samtools/htslib/issues?q=is%3Aissue%20aut...
To computer scientists, it's pretty obvious that DNA used as input to a program could be maliciously crafted.
Now if DNA contained an encoded turing-complete language that the lab ends up executing...
But I think we're some way off from achieving that.
The issue is that they forced a buffer to overflow--they put N bytes of data into a bucket that was can only hold n bytes. The extra N-n bytes were carefully chosen so that they would do something "interesting" when they spill out of the bucket and into the program's code (there are ways of avoiding this, like the No-eXcecute bit, which I guess were ignored/turned off for this demo).
In some ways, this is easier to do with unstructured data. If there was some specific format, the overflowed data would have to fit into that format AND do something malicious.
1. The DNA is sequenced. 2. Sequence data are compressed with a version of fqzcomp which has been modified to use/overflow a static buffer. 3. Something about this particular DNA sequence overflows a buffer in fqzcomp 4. The overflow contains some kind of exploit.
The paper is a little vague about where they inserted the exploit into fzcomp(https://fqzcomp.sourceforge.io/), but it does process the DNA sequence a block at a time. It tracks the frequency distribution of nucleotides so it can model them for compression. I hope the exploit was something really clever, like finding a DNA sequence that puts the encoder in a weird state, but it's also possible they just set BLK_SIZE to 1 or something like that.
Even with code written in unsafe languages, ASLR and the XD/NX bit makes this class of exploits almost completely obsolete. I'm assuming the DNA software they were using had neither turned on.
I'm a bit exhausted of hearing about buffer overflow exploits. There's nothing smart or clever about them (anymore).
Most languages can be safe with a safe implementation and most languages can be unsafe with an unsafe implementation.
Just use a safe implementation next time, or go all-in and formally verify your programs.
I don't think -- an example off the top of my head, don't nitpick please -- that Clojure and Erlang/Elixir are that easily exploited with buffer overflows. I'd even say they are immune but I am not a security researcher.
I dread (but am already certain it will eventually happen) the day when some kind of gene therapy cure will be customized to your DNA and will contain some absolutely nasty bio-DRM (think turbo cancer) if it gets applied to the wrong person, or past a date, etc.
Wow, incredible work guys. Really a milestone here.
I guess if it was already well-established that reading programmable DNA was a thing, then this is about as innovative as "you can put malicious programs on flash drives, or as email attachments."
But in that case, what would they have to do that's interesting from a biotech+compsci perspective to show impressive work? Have DNA that can find security vulnerabilities on its own? Or somehow create a stack that can use a program on a DNA strand to then attack some more well-known, real security vulnerability? That seems about the same as just running code from DNA, which is what they demonstrated?
But if most people aren't aware of DNA programming, isn't this still cool? Am I missing something else?
Need to sanitize those inputs!
Especially the part when in the original movie two garbage truck drivers were remotely hacked and their identities were completely replaced. That could probably happen by checking out a certain street sign.
Scary.