search

GaloisInc / BESSPIN-Tool-Suite

The core tool of the BESSPIN Framework.
Other
6 stars 2 forks source link

Drafting a complete action plan for FreeRTOS #74

Closed rtadros125 closed 4 years ago

rtadros125 commented 4 years ago

We're almost at sprint#1 midpoint, and we're still going back and forth with this. We need to make all the decisions soon.

rtadros125 commented 4 years ago

@rod-chapman I will un-assign you from the TLS ticket and move it back to the backlog. I will be moving other performers to work on the new FreeRTOSmirror and doing the mbdeTLS work (and maybe https). Since both of these are super clear pre-requisites to any work you'd do on top, and the OTA seems a non-trivial task. Sounds good?

rod-chapman commented 4 years ago

@rtadros-Galois @kiniry - please take a look at https://github.com/DARPA-SSITH-Demonstrators/SSITH-FETT-Docs/blob/ota_design/applications/freertos_ota_design.md

This is my current "strawman" for how the OTA service will work. Happy to talk about it later if you like, or we can collect comments in a PR...

rod-chapman commented 4 years ago

@abakst - you should probably have a look at the link above too...

rtadros125 commented 4 years ago

@rod-chapman Thanks a lot for the document. I have the following questions:

  1. When you say "HTTP", do you mean "non-HTTPS"? If so, then why not-HTTPS?
  2. In the win conditions, I see "if a participant can craft an OTA payload". I feel I mis-understanding something here. My understanding was that the researchers will have the ability to trigger an OTA push, but they won't have access to the payloads. If they can craft any payload, that would be a definite win. What am I missing?
  3. regarding your question in the TFTP point "is this ok for FETT"? If the demo/library is working on the FPGA with our new FreeRTOS mirror, then it's ok. FreeRTOS 9 is also before the patches we don't want to include, then it has a definite "ok".
  4. I got confused again. Why do we need TFTP server on FreeRTOS? Don't we need only a TFTP client? And the server being on one of our hosts? Why does the document say the opposite?
  5. The first part of the document says we'll be using OTA through HTTP, then later on, it says TFTP. What am I missing? Did you mean that "Overall, this bug bounty program will have two applications: OTA and HTTPS", and then the TFTP part is only related to OTA?
  6. Answering the encryption question, I'd say yes, the confidentiality of the payload is important.
  7. Though it's not mentioned, I'd like to ask explicitly: we'll do FTP over TLS, right?
  8. The entire library FreeRTOS+TCP will be working no problem. Why do you need the UDP functions? Thanks!
rod-chapman commented 4 years ago
  1. If we are required to demo HTTPS not HTTP, then that's just my mistake...
  2. Well.. the "payload" (i.e. the file that gets pushed from the bastion host to the target via TFTP) is signed by a private key, so creating one will be very hard if the attackers don't know they correct private signing key. If they push a payload with an invalid signature, then the target end will reject its which is not a win.
  3. I specifically asking if the "FreeRTOS-modified GPL2" is acceptable for FETT. (For instance, I assume you DON'T want the GPL2 transitively infecting all of our code???)
  4. The target side is a TFTP Server. Most of the time it just sits there waiting for a connection doing nothing. The attackers will use "tftp" (the client application on Linux) to push a file to the target.
  5. I didn't intend that. For me - the OTA and HTTPS services are not related really, but I do think they should be distinct tasks in the same FreeRTOS binary, and will share the FAT filesystem.
  6. Why is confidentiality important? For who? Again what forms of attack. If the ability to gain access to the content of on OTA payload to "reverse engineer" the binary was important, then yes - encryption would be used, but we haven't set that as a win condition.
  7. FTP? What's FTP got to do with it? TFTP and FTP are totally different, right? TFTP is there to support OTA... nothing else.
  8. TFTP is built on top of UDP.
rtadros125 commented 4 years ago
  1. Got it; thanks.
  2. Yeah. I don't see how they can succeed with the OTA tbh, but this is not our job. I just wanted to confirm that they are not going to craft their own payloads (or at least, this is not the intended path).
  3. Ah I misunderstood the point. This seems like a licensing question. I think we can use it yeah. The problem would happen if we need to sell our software as a closed-source. But if we just use it, then it should be ok. @rfoot hey Reuben, can you please confirm this: there was a C library that is under GPLv2 license, it wsa included in FreeRTOS libraries. Then, after amazon bought FreeRTOS, they apparently migrated towards MIT license, and since then, they did not include that library in their code base. Can we use that library in FETT?
  4. I am still confused sorry. Isn't the TFTP server hosting the files and sending them upon request. Doesn't this make the target a TFTP client only? The target isn't hosting any file; isn't it?
  5. Got it; thanks. The title of the document confused me. It say OTA design, but the first part was about the whole project.
  6. I feel we're on two different wavelengths here. Can you please elaborate on the difference between the two scenarios (confidentiality, and no-confidentiality), so that we're sure we're speaking about the same things. Thanks.

7&8. Now I got what was confusing me. I didn't know about TFTP; I thought it's the same as FTP. Huh, hmmmmm, I am not sure if I like this. My two concerns are: 1. FreeRTOS networking is not great, I mean the drivers are not that reliable, so I am not sure if relying on UDP makes sense tbh. It might affect our target robustness in terms of basic-functionality. 2. This can be trivially spoofed. I am not sure how I feel about having a bug bounty contest where we ask the hackers to attack our OTA, and then we send our firmwares over UDP. What am I missing here?

jrtc27 commented 4 years ago

7&8. Now I got what was confusing me. I didn't know about TFTP; I thought it's the same as FTP. Huh, hmmmmm, I am not sure if I like this. My two concerns are: 1. FreeRTOS networking is not great, I mean the drivers are not that reliable, so I am not sure if relying on UDP makes sense tbh. It might affect our target robustness in terms of basic-functionality.

UDP vs TCP won't make a difference here. The drivers are a bit unreliable, but I've never seen them corrupt data, just decide to not send/receive packets. TFTP has its own retry mechanism on top of UDP so dropping packets can be tolerated just like TCP, but will nonetheless slow it down.

  1. This can be trivially spoofed. I am not sure how I feel about having a bug bounty contest where we ask the hackers to attack our OTA, and then we send our firmwares over UDP. What am I missing here?

You just have to not do the crypto at the transport layer. Your OTA receives data unauthenticated and in the clear, and the payload itself that goes over TFTP should be signed. Just like what happens when you download firmware updates from manufacturers' websites and then separately upload them to your home router via its web interface (or at least used to, maybe not these days).

rtadros125 commented 4 years ago

I agree. Thanks for the clarification. Then number (6) becomes critical here. We have to do the crypto part in a perfect way if we're gonna leave the transport layer wide open. Right?

abakst commented 4 years ago

I don't have additional points to make on the points that have been discussed, it seems like most of those have been resolved and the plan looks reasonable to me.

My feeling is that confidentiality of the update blob is not critical for the purposes of FETT, though discovering an information leak that could leak the contents of the payload might be interesting. But in that case it would be just as interesting if the payload were pushed unencrypted (as I understand it, the network itself is not a target, so a "win" would be reading confidential data from FreeRTOS memory)

rod-chapman commented 4 years ago

Thanks for the comments everyone.

Point 4: Perhaps "server" is the wrong word - our FETT target will be running a service that waits for, accepts, and services TFTP requests from the bastion host. This is playing the role of the "tftpd" binary on a traditional system. The attackers use "tftp" on the bastion host to initiate (i.e. "push") a file to be transferred to the target.

Point 6. The "payload" here is really just a text file (or perhaps HTML), not a commercially sensitive firmware binary. Besides, the attackers will be trying to inject their own payloads into the target (e.g. an HTML file that says "You have been hacked.") so there's no loss in it not being encrypted since the attackers already know what it says! The scenario where confidentiality does matter is where "we" (playing the role of the IoT device manufacturer) want to ship some super secret new binary code to our devices in the field, and we don't want anyone intercepting it and being able to reverse engineer it... but... that's not a win condition for this competition... (at least, I have decided that it's not... I guess Joe could overrule and say that it is...)

Encrypting the payload is not really a problem. The big problem is how you get the secret symmetric key into the target and keep it secret. This is a big problem, unless you have a proper HSM with secure key storage facility. According to Reuben, our HSM doesn't have that... :-(

So.. I can see 2 win scenarios:

WS1: Attacker crafts a file to upload, or perhaps write a malicious TFTP client that exploits some vulnerability in FreeRTOS or the UDP/IP stack, or in our own OTA code to brick the target. Denial of service = win!

WS1: Attacker somehow manages (as above) to bypass the OTA signature verification and gets a payload file "nasty.txt" stored onto the FAT filesystem. The attacker then fires up a web browser, connects to the target via HTTPS and asks the server for https://target/nasty.txt and voila is able to prove that they hacked us.

rod-chapman commented 4 years ago

PS... I hope to talk to Dylan H soon to confirm the exact capabilities of the hardware HSM. Reuben said it can do SHA2-384 and AES, but NOT any elliptic curve and/or ECDSA stuff. As I said, Reuben also reports no secure key storage.

My plan is to start with implementation of all that purely in software, then move over to use the HSM as and when it (and its software drivers) become available.

Another benefit of that approach is that I should be able to prototype the whole thing on a vanilla Linux box, which I like.

rtadros125 commented 4 years ago

Ok, I think we have a plan then (this sentence is giving me a deja vu):

Todo list (OTA pre-requisites):