
D-Link publishes code-signing private keys by mistake - svenfaw
https://translate.google.com/translate?sl=nl&tl=en&js=y&prev=_t&hl=nl&ie=UTF-8&u=http%3A%2F%2Ftweakers.net%2Fnieuws%2F105137%2Fd-link-blundert-met-vrijgeven-privesleutels-van-certificaten.html&edit-text=&act=url
======
radicalbyte
Here's my translation:

D-link has accidentally published private keys for certificates which they use
to sign their software. It was possible to extract the keys from the
manufacturers open source firmware packages. That made it possible for
Criminals to abuse the certificates.

[short explanation of how the certs work for n00bs]

The mistake was find by bartvbl who informed the reporter of the problem. He
had bought a D-Link DCS-5020L security camera and wanted to download the
firmware. D-Link makes the source from lots of firmware available under a GPL
license. "After looking through the files it turned out that the they
contained the private keys which are used to sign the code" reported bartbvl,
"It gets worse - some of the batch files contained the commands and
passphrases that were needed [to sign the software".

The user was able to confirm that the key could be used by signing a file that
wasn't from D-Link. The certificate expired at the start of september, which
means that the trick no longer works. Even now that the expiry date has
passed, software which has been signed will still be seen as being valid.
Windows only shows a certificate error after the certificates have been
withdrawn. This withdrawal has already happened so this [bug/failure] cannot
be abused.

Software security specialists Fox-IT confirm the findings. Yonathan Klijnsma,
a researcher from the company: "The certificate was indeed in one of the
firmware packages, version 1.00b03, the source of which was released on
27-feb-2015. The cert was thus published before it expired, which is a big
error". He [, Yonathan,] found four other certificates in the same folder.

D-Link have in the meantime released new versions of the firmware which do not
contain the certificates. In a statement the company told us that they
regularly update the firmware in order to 'conform to the latest security and
quality standards'. They emphasized that there is no question of [malicious]
premeditation. "D-Link [does everything to prevent development of backdoors,
bla bla boilerplate PR speak, etc etc]". D-Link promised Tweakers that they
will release a new firmware next week which contains further fixes for the
security problems.

~~~
radicalbyte
TLDR: D-Link accidentally included their certs and batch files containing
passcodes in a beta package of their firmware. Problem has been fixed so it's
no longer an issue.

~~~
jestar_jokin
Has the problem been fixed? I would think the cat's out of the bag; the
private keys are already out in the wild (I assume), so all D-Link hardware is
now vulnerable to exploitation.

------
mindslight
> _" It turned out what to look through the files that were in private keys to
> sign with code", reports bartvbl, "In fact, in some batch files were the
> commands and pass phrases that were needed."_

A company _finally_ holds up their end of the GPL by including all source
needed to create a working build, and it's called a mistake!?

For every device requiring images to be signed with a specific key, this is
exactly what the manufacturer should be forced to release!

~~~
eridius
This is absolutely a mistake. The whole point of requiring the firmware to be
signed with a specific private key is to prevent third parties from installing
their own custom firmware (e.g. to prevent malicious actors from installing
malware onto the device). If you want to let everyone install their own build,
then just don't require the code signature (or, alternatively, create a
program where third parties can request a certificate signed with your master,
so they can then sign their own binaries, similar to how iOS development
works).

> _For every device requiring images to be signed with a specific key, this is
> exactly what the manufacturer should be forced to release!_

What do you mean by "should" here? If the source is covered by GPLv3, then
yeah, if they use code-signing they need to have some way to let you get
around it. That's the point of the anti-tivoization clause. But if the
software is distributed under GPLv2, or any other license, then there's no
anti-tivoization restriction, and therefore no "should" about it.

~~~
mindslight
> _The whole point of requiring the firmware to be signed with a specific
> private key is to prevent third parties from installing their own custom
> firmware_

Yes, which is blatantly anti-GPL2. I really wish any Linux copyright holder
would step up to the plate and force the argument that since code+signature is
the functional unit, adding the signature makes a derivative work and its
source must be released in the preferred form for modification. The entire
point of the GPL2 is that a developer who creates code and receives a modified
version back should be able to modify that instance of code - tivoization is
entering into the license in bad faith.

Of course going GPL3 would make for a more solid foundation for doing so, but
clarifying this subject directly conflicts with the desires of the proprietary
sponsors - Google etc.

~~~
DannyBee
The GPL is rarely litigated. What you are talking about is not blatantly anti-
gplv2

IAAL (and an open source licensing lawyer at that, for many years). I'm also a
contributor to FSF projects :)

Even I would tell you the GPLv2 almost certainly does not cover code signing.

It's actually very epxlicit about what needs to be there: That's the whole
problem with gplv2: " For an executable work, complete source code means all
the source code for all modules it contains, plus any associated interface
definition files, plus the scripts used to control compilation and
installation of the executable."

That's it. It very clearly and explicitly says what you must include, and
installation keys in not there.

It even says 'scripts used _to control_ installation", not "scripts involved
in installation" or anything like that.

~~~
mindslight
> _What you are talking about is not blatantly anti-gplv2_

Someone who buys a router running locked down Linux lacks two out of the four
essential freedoms, so yes tivoization is blatantly anti-gpl2. I would say
this is a popular (edit: non-legal) opinion, especially given the upvotes I
have received.

But the legal interpretation may diverge from the spirit and purpose of the
license, so I would love to hear the opinions of an experienced lawyer...

I don't see any real difference between "scripts used to control installation"
and "scripts involved in installation", "installation scripts", "scripts used
to install" etc, unless the specific wording has been used to create a huge
loophole. But as you say, there is not much case law so I don't think this is
so.

What exactly would you say that "scripts used to control ... installation"
includes?

A script that says "cp -f a.out /bin/" most certainly qualifies, no?

And how about "st-flash write foo.bin 0x8000000" ?

And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-
ADDR.txt is still considered part of the "scripts" in the legal sense?

Surely you're not arguing that these scripts "perform" the installation rather
than "control" it ?

~~~
georgemcbay
"I would say this is a popular opinion"

Completely irrelevant to the legality question.

The fact that Eben Moglen and the FSF crafted the GPLv3 specifically to avoid
future "tivoization" should serve as a pretty good indication that even the
FSF's lawyers don't believe there is a (court-case winnable) legal infraction
here when it comes to GPLv2 code, though everyone would agree the spirit and
the purpose of the license often isn't being respected (which is, again,
irrelevant to the actual legality when it comes to copyright law).

~~~
wtallis
The addition of explicit anti-tivoization language to v3 does not imply that
they think v2 _couldn 't_ have that effect, just that they thought it would be
nice to have a stronger case. The GPLv3 makes it an almost-guaranteed win (to
the extent that such a thing exists), but that doesn't mean trying with the
GPLv2 is a guaranteed loss.

And this conversation is clearly about more than just which legal
interpretations hold force. It's about the spirit of the license and how
closely it aligns (or not) with the interests of its more prominent users who
have the standing and resources to at least _try_ to to fight against uses
that go against the spirit of the license.

~~~
DannyBee
"The addition of explicit anti-tivoization language to v3 does not imply that
they think v2 couldn't have that effect, just that they thought it would be
nice to have a stronger case."

While true, having been around then and knowing what went on in the drafting
committees, it's definitely the case that they were told they didn't think
they had a winnable case with the GPLv2 language ;)

If they had thought they did, they also would likely have gone after TiVO :)

------
pwnna
Google translate doesn't seem to be 100% clear, but the signing key is
actually for some windows software, rather than device firmware. Is that
correct?

~~~
callesgg
From what i understood they explained it with the windows software thing but
the key we are talking about is actually used to sign firmware.

Since most routers dont require signed firmware this just makes the few that
does as bad as them.

Personally i would think the likely hood that the key would be used for
good(Open WRT) is far greater than that it would be used for bad.

On a general note:

Consumer routers are in my experience generally very easy to hack in to stuff
like
[http://192.168.1.1/setting.cgi?setname=`echo](http://192.168.1.1/setting.cgi?setname=`echo)
'password' | passwd` is not uncommon so altering the firmware is seldom
needed.

------
tjohns
This is precisely why you store your signing keys in a HSM attached to your
build server, precisely so that it's impossible to leak them (either by malice
or incompetence).

~~~
johansch
[https://en.wikipedia.org/wiki/Hardware_security_module](https://en.wikipedia.org/wiki/Hardware_security_module)
\- since the parent poster seemed to feel the need to use an extremely
uncommon acronym to show his or her superiority.

~~~
estsauver
It's really not that uncommon.

I think "If there's an AWS product for it, it's not that obscure" is a
reasonable standard. You could pretty clearly google "keys HSM" and it would
show up.

~~~
ajnin
I don't think that "can be found on Google" is a very good criterion for
commonness...

~~~
simoncion
Given that there's _so_ much out there to know, and that each field has its
own commonly-used acronyms, I _do_ think that if you can find the -correct-
definition of an acronym in the first ten Google search results, then (IMO)
that acronym is common.

As an example: Would you consider RAM to be a common acronym? If you work with
computers you're very likely to answer "Yes." or "Hell yes." to that question.
But, there are _many_ people out there who have no idea how to expand RAM into
its parts, and may not have _ever_ heard the term. Yet, the expansion of RAM
is in the top ten Google search results for the term. (It's in my top two.)

Additionally, I know what an HSM is, and I don't even work in a field that
requires their use.

------
smcquaid
Horrible .. but the certs expired in early September so not currently relevant
except to monitor history/past infections/malicious activity

~~~
05
Even if the expiration date is checked, it's easy enough to change the date
before flashing new firmware

------
aqwwe
if this allows anyone to use their D-Link hardware however they see fit, I'm
all for this kind of mistakes...

------
jheriko
and when was code signing any real kind of security anyway?

its always felt more like a protection racket to me... especially when you can
takes someone's codesigned stuff and resign it. getting the ability to code
sign requires just money, time and a bare minimum of paperwork...

the trusted authority on these things is completely untrustworthy by the
nature of their business imo.

------
devy
> Furthermore, the company Tweakers promises that early next week new firmware
> comes out which security issues are also resolved.

Very assuring! I am worried about my other D-Link home surveillance cam
products now.

------
rasz_pl
It is NOT by mistake. Dlink engineers are INCREDIBLY INCOMPETENT.

Let me remind you this excellent piece: [http://www.devttys0.com/2015/04/what-
the-ridiculous-fuck-d-l...](http://www.devttys0.com/2015/04/what-the-
ridiculous-fuck-d-link/)

~~~
mahouse
Don't say "incompetent" when you mean "they don't give a fuck" or "this
software was subcontracted to the India".

~~~
fixermark
"not having or showing the necessary skills to do something successfully"

Demonstration of necessary skills failed. Incompetent.

------
jeremonda
The fact that D-Link published code-signing private keys by mistake, is why we
need ethics in code-signing.

