summaryrefslogtreecommitdiffstats
path: root/CAN-binder/libs/nanopb/docs/security.rst
diff options
context:
space:
mode:
authorRomain Forlot <romain.forlot@iot.bzh>2017-06-20 10:24:05 +0000
committerRomain Forlot <romain.forlot@iot.bzh>2017-06-20 10:24:05 +0000
commit32e25cbca210a359b09768537b6f443fe90a3070 (patch)
tree3309794c15d8a8f8e9c1c08cad072ee1378813ba /CAN-binder/libs/nanopb/docs/security.rst
parent76c43dec62b2e21cd6446360c00d4fe6b437533f (diff)
Separation Generator to a dedicated repo
Change-Id: Id94831651c3266861435272a6e36c7884bef2c45 Signed-off-by: Romain Forlot <romain.forlot@iot.bzh>
Diffstat (limited to 'CAN-binder/libs/nanopb/docs/security.rst')
-rw-r--r--CAN-binder/libs/nanopb/docs/security.rst84
1 files changed, 0 insertions, 84 deletions
diff --git a/CAN-binder/libs/nanopb/docs/security.rst b/CAN-binder/libs/nanopb/docs/security.rst
deleted file mode 100644
index d8546122..00000000
--- a/CAN-binder/libs/nanopb/docs/security.rst
+++ /dev/null
@@ -1,84 +0,0 @@
-======================
-Nanopb: Security model
-======================
-
-.. include :: menu.rst
-
-.. contents ::
-
-
-
-Importance of security in a Protocol Buffers library
-====================================================
-In the context of protocol buffers, security comes into play when decoding
-untrusted data. Naturally, if the attacker can modify the contents of a
-protocol buffers message, he can feed the application any values possible.
-Therefore the application itself must be prepared to receive untrusted values.
-
-Where nanopb plays a part is preventing the attacker from running arbitrary
-code on the target system. Mostly this means that there must not be any
-possibility to cause buffer overruns, memory corruption or invalid pointers
-by the means of crafting a malicious message.
-
-Division of trusted and untrusted data
-======================================
-The following data is regarded as **trusted**. It must be under the control of
-the application writer. Malicious data in these structures could cause
-security issues, such as execution of arbitrary code:
-
-1. Callback, pointer and extension fields in message structures given to
- pb_encode() and pb_decode(). These fields are memory pointers, and are
- generated depending on the message definition in the .proto file.
-2. The automatically generated field definitions, i.e. *pb_field_t* lists.
-3. Contents of the *pb_istream_t* and *pb_ostream_t* structures (this does not
- mean the contents of the stream itself, just the stream definition).
-
-The following data is regarded as **untrusted**. Invalid/malicious data in
-these will cause "garbage in, garbage out" behaviour. It will not cause
-buffer overflows, information disclosure or other security problems:
-
-1. All data read from *pb_istream_t*.
-2. All fields in message structures, except:
-
- - callbacks (*pb_callback_t* structures)
- - pointer fields (malloc support) and *_count* fields for pointers
- - extensions (*pb_extension_t* structures)
-
-Invariants
-==========
-The following invariants are maintained during operation, even if the
-untrusted data has been maliciously crafted:
-
-1. Nanopb will never read more than *bytes_left* bytes from *pb_istream_t*.
-2. Nanopb will never write more than *max_size* bytes to *pb_ostream_t*.
-3. Nanopb will never access memory out of bounds of the message structure.
-4. After pb_decode() returns successfully, the message structure will be
- internally consistent:
-
- - The *count* fields of arrays will not exceed the array size.
- - The *size* field of bytes will not exceed the allocated size.
- - All string fields will have null terminator.
-
-5. After pb_encode() returns successfully, the resulting message is a valid
- protocol buffers message. (Except if user-defined callbacks write incorrect
- data.)
-
-Further considerations
-======================
-Even if the nanopb library is free of any security issues, there are still
-several possible attack vectors that the application author must consider.
-The following list is not comprehensive:
-
-1. Stack usage may depend on the contents of the message. The message
- definition places an upper bound on how much stack will be used. Tests
- should be run with all fields present, to record the maximum possible
- stack usage.
-2. Callbacks can do anything. The code for the callbacks must be carefully
- checked if they are used with untrusted data.
-3. If using stream input, a maximum size should be set in *pb_istream_t* to
- stop a denial of service attack from using an infinite message.
-4. If using network sockets as streams, a timeout should be set to stop
- denial of service attacks.
-5. If using *malloc()* support, some method of limiting memory use should be
- employed. This can be done by defining custom *pb_realloc()* function.
- Nanopb will properly detect and handle failed memory allocations.