0

I need to have over the air (OTA) update for a Raspberry Pi board running Debian. I'm thinking of running a cron job on an apt-get update and have my own private repository. So I can push my updates to the repository and the system will automatically pull these updates.

My question is in regard with the security. Is this a safe way of doing OTA or could this potentially allow hackers to push malicious "updates" to my device?

Kousha
  • 32,871
  • 51
  • 172
  • 296
  • Depends on how much care you take in original downloads, the physical security of your radio environment (or its encryption), and how much of a target you are. – mpez0 Mar 05 '15 at 17:17
  • Personally I think you are being very very paranoid - https://www.packtpub.com/books/content/create-local-ubuntu-repository-using-apt-mirror-and-apt-cacher You should look at running your own local repo - That is so long as you feel that the legitimate repos have not had any helping hends from NSA and so on ... hahaha – V H Mar 05 '15 at 17:29
  • You can look at this one: https://mender.io/resources/whitepapers/iot-device-security Nicely explained security issues related to various typed of the OTA updates for IoT devices. It is more than application updates though. – codewarrior Nov 10 '21 at 07:25

2 Answers2

0

If you do a apt-get update just your sources.lst gets renewed.

In case you mean apt-get update && apt-get upgrade (which actually updates your system) I think it does not depend on how you invoke your update but rather on how secure the server is which holds the repository and of course the source where you are getting your new packages (the most save way would be to build them yourself from source).

Merl
  • 96
  • 1
  • 6
0

Ran into the same situation, hosting a python script. What could be the attack vectors:

  1. manipulate your repo on the server
  2. man in the middle attack
  3. direct attack to the client

For 1 and 2 we should analyse the code before starting: A CRC might be retrieved from the server to verify. Unfortunately automation would render this protection unusable. HTTPS is not helping for 1, only a secure server and may be a ciphered directory name. /2q3r82fnqwrt324w978/23r82fj2q.py

For all points it would make sense to check for commands in the script, e.g. sudo, or from https://www.kevinlondon.com/2015/07/26/dangerous-python-functions.html

Finally, yet importantly, an idea to compare the new to the old code and only accept minor changes. However this prevents rewriting the code.

J. M. Arnold
  • 6,261
  • 3
  • 20
  • 38
Gerfried
  • 1