levi
Still fresh, damnit!
See https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080
The Pyra's GSM chip presumably runs some sort of OS to parse AT commands and deal with real-time parts of phone connectivity. If the source for that OS was built using a preprocessor named ASN1C to boilerplate up some of the code to talk some of the primitive protocols that GSM protocols require, then it'll be built including a lib that contains an integer overflow that results in a buffer overflow.
Do you have the source for that component? As far as I can tell, windows builds will include 'asn1rt_a.lib' and presumably something similarly named will be included for linux builds if ASN1C has been used - you might even be able to find that in a binary blob, if you can get that.
If the Pyra is affected, the Linux OS should be mostly immune since the chip OS can only talk to Linux through AT commands and responses, but it's feasible this overflow could make the chip call premium rate numbers without you being aware, for example.
The Pyra's GSM chip presumably runs some sort of OS to parse AT commands and deal with real-time parts of phone connectivity. If the source for that OS was built using a preprocessor named ASN1C to boilerplate up some of the code to talk some of the primitive protocols that GSM protocols require, then it'll be built including a lib that contains an integer overflow that results in a buffer overflow.
Do you have the source for that component? As far as I can tell, windows builds will include 'asn1rt_a.lib' and presumably something similarly named will be included for linux builds if ASN1C has been used - you might even be able to find that in a binary blob, if you can get that.
If the Pyra is affected, the Linux OS should be mostly immune since the chip OS can only talk to Linux through AT commands and responses, but it's feasible this overflow could make the chip call premium rate numbers without you being aware, for example.
