[SystemSafety] "Ripple20 vulnerabilities will haunt the IoT landscape for years to come"

Peter Bernard Ladkin ladkin at causalis.com
Thu Jun 18 11:01:13 CEST 2020



On 2020-06-18 00:28 , Jon Hind wrote:
> 
> Am I worrying too much, or is this vindication ?

Probably you are not worrying enough. Note that this isn't just IoT. And it's not just some small SW
vendor with a lightweight "convenient" TCP/IP stack. Last year it was VxWorks.

Note also that the four vulnerabilities mentioned with a severity rating of 10/9.8 are all data
typing issues. Devices might get cuter, but the logic issues are the "classic" issues.

The question is what to do about these issues that have been sitting around ("lurking" is hardly the
right word) since the Internet became a thing 25 years ago. I use the phrase "Extended data type
vulnerability" (EDTV).

I have been saying for a while that most of the issues turning up on the CVE list are extended data
typing vulnerabilities. This has got zero traction, I suspect because most of the people I talk with
are engineers, not necessarily computer scientists, who don't really know much, if anything, about
programming language design.

A story about that. Rather, a repeated story. A few years ago, I was advising people who had useful,
bespoke SW for a particular application which had safety-relevant features. It was assessed and
authorised by the German regulator, but some other countries were interested. My clients wanted to
sell it internationally, and thereby needed 61508 conformity. Retroactively, since the SW already
existed. Almost impossible to do, except at that time the "new" proven-in-use criteria had just been
published. I explained general principles of SW assurance. The application used a bespoke "logic
language", interpreted not compiled. Does it have a semantics? ("What's that?") Well, suppose you
have a branch "IF (A & B) DO <something>". When the interpreter interprets this, it needs to check
whether A and B both hold, and only in the case in which they both hold is it to execute
<something>. ("Well, why wouldn't it? It says so, right there: A & B"). Yes, but you need to provide
some kind of assurance that what is written is what is in fact done by the interpreter; maybe the
interpreter just looks at A and omits to check B. ("But this language and interpreter was designed
by <very important company>; why would it do that?") Well, maybe <very important company> has all
the assurance already documented - could you ask them maybe? (My guess: no they don't.)

Yet another piece of evidence for me that there is no way to give a crash course in SW assurance in
ten minutes.

So what to do about EDTV? I am almost tempted to have two stickers made. "Data type correct" and
"Vulnerable to data type insecurities". The former I'll give out to anyone who can provide me with
appropriate assurance. The latter I'll just give out to anyone - there are bound to be some people
who will post them surreptitiously on any unattended machine......

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
Styelfy Bleibgsnd
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20200618/cf63a879/attachment-0001.sig>


More information about the systemsafety mailing list