[time-nuts] More GPS troubles

David davidwhess at gmail.com
Thu Jan 17 14:59:20 UTC 2013


On Thu, 17 Jan 2013 06:02:51 -0800, Jim Lux <jimlux at earthlink.net>
wrote:

>On 1/17/13 2:52 AM, Hal Murray wrote:
>> How to bring down mission-critical GPS networks with $2,500
>>
>> http://tinyurl.com/boe2cdh
>> http://arstechnica.com/security/2012/12/how-to-bring-down-mission-critical-gps
>> -networks-with-2500/
>
>I think this came up a few months ago.
>
>the article is a bit over the top, but does describe the basic mechanism 
>used:
>
>"exploits software bugs in the underlying receivers"
>
>For instance, they say
>"Since the Arbiter showed no ability to compare the settings to internal 
>clock settings, it suffered permanent damage when it was exposed to the 
>exploit."
>
>Permanent damage?  As in components failed?  No, I think a factory reset 
>would restore it to function.

Here is a copy of the research paper which was linked here not long
ago:

http://users.ece.cmu.edu/~dbrumley/courses/18487-f12/readings/Nov28_GPS.pdf

The Trimble NetRS had what they think was a divide by zero bug in the
firmware which caused perpetual reboots until a hardware reset because
the spoofed ephemeris data which caused the reset was stored in
nonvolatile memory.

They actually posted video of the attack against the NetRS although
the research paper is more informative:

http://www.youtube.com/watch?v=6K8dD2PCI6s

The Arbiter which suffered from the date de-synchronization attack on
the other hand had *no way* to reset the nonvolatile week epoch after
the attack spoofed rollover events so the damage was indeed permanent
although limited to reporting the wrong date and apparently producing
the wrong timing although I am not sure why the week epoch would
affect the microsecond timing.

>I suspect that most modern GPS receivers also have loadable/replaceable 
>firmware, so as "divide by zero" bugs and the like are found, then it 
>can be fixed, particularly if it's in something like a high accuracy 
>reference network.
>
>A pain, to be sure.

If the GPS receiver is self contained within a larger system, it may
not be possible to update and if it is, it would still require the GPS
receiver manufacturer to produce and release the update firmware.

>I think the threat is a bit overstated, too.  Sure, the hardware costs 
><$20k, but it's operated by a team of fairly sophisticated people who 
>programmed it for each specific victim (that is, every receiver has a 
>different vulnerability).  Just because one has identified a threat 
>vector doesn't mean that there's any incentive to use it:  Many have 
>proposed scenarios where denying GPS has some value, but considering it 
>as a potential criminal scenario you'd also need:

The 7 receivers shared many of the 4 (5 if you count spoofing but all
non-military receivers suffer from that) vulnerabilities.  They had to
program the hardware for each vulnerability but not each receiver.

>1) resources to execute the threat (that team of grad students from CMU, 
>knowledge of the specific receivers to be attacked and their specific 
>vulnerabilities, etc.)

This will only get cheaper and easier to do in the future.  What a
team of graduate students do today will become possible for one
graduate student and then one undergraduate student.

>2) A decent scenario asking what form the denial takes (e.g. are you 
>spoofing, or what)
>3) A way to radiate these signals in a way that you won't get caught. 
>There are a fair number of folks out there working on and doing systems 
>to detect GPS jamming.

Just detecting the GPS jamming or spoofing by itself does not catch
the perpetrators or their device.  Given how small a 1.5 GHz
transmitting antenna can be even if it is directional and the
difficulties caused by multipath and reflections at 1.5 GHz, tracking
the transmitter down could be very difficult even if the operators do
not take additional steps to prevent that.



More information about the time-nuts mailing list