Hacker News new | past | comments | ask | show | jobs | submit login

Calling this a backdoor is an extreme measure. I wasn't able to see any working example, nor any responsible disclosure which seems bad.

Also, if somebody has the ability to run arbitrary code on your machine, I would think that it's game over at that point - backdoor or not. This is not a remote exploitable backdoor it seems.




This is unequivocally a backdoor, by definition. They backdoored their own API for the benefit of their own plugin being allowed to run unauthenticated.

What we can't say is whether this is a backdoor created for nefarious purposes. All we can say is that the backdoor exists and, if we accept that authentication on this API is valuable, then it's an egregious violation of security principles by effectively having some hardcoded credentials which bypass a security layer.

You can wave it away as local-only and claim that if you have code running on the box, it's already pwned, but this is rationalization: this backdoor bypasses a layer of security that is otherwise present. Can an otherwise unprivileged process (e.g. one from another user) call this API? The details are not specified.

I tend to think this looks more like incompetence perpetrated a long time ago and forgotten, but that doesn't make it any less of a back door.


> They backdoored their own API for the benefit of their own plugin being allowed to run unauthenticated.

Well, something with its name.

"Curiously, the actual Skype Dashboard widget does not seem to utilize the backdoor into the Skype Desktop API despite the name "Skype Dashbd Wdgt Plugin"."


Well, it seems obvious that some version of this plugin probably used to use this API and doesn't anymore.


> Calling this a backdoor is an extreme measure.

How else would you call the possibility to sidestep access controls by setting a specific string as identifier?

> I wasn't able to see any working example, nor any responsible disclosure which seems bad. First, those two statements kind of contradict each other. Second, from the advisory linked from the article:

    10/13/2016 - Vulnerability disclosed to vendor
    10/26/2016 - Patch released by vendor
    12/12/2016 - Advisory published
> Also, if somebody has the ability to run arbitrary code on your machine, I would think that it's game over at that point.

Yes, it has been game over all the time: People execute arbitrary code on their machines by installing free programs they downloaded from somewhere. But that's not the point. The point is that some application that has control over very sensitive data includes a possibility (to avoid the word "backdoor") to access that data without user-confirmation and alarms, which are otherwise built into the application on a design level.


Well, let's just look at the source code and we can see when/where it got added.


If it's really malicious and was done with coordination at MS, what would stop them from putting a backdoor in a binary build?

Sure people who build it from source would be protected, but that's still not the majority of users for a product like Skype. I don't get the OSS cause being shoehorned into every conversation.


Can you verify the binaries by reproducing them and comparing hashes? (obviously not of the whole binary but maybe some portion)

That would protect the users of those binaries.


Deterministic compilation isn't commonplace yet. I'm not even sure if it's really usable at all yet.

Generally, we rely on signed binaries.


So the signature gives you confidence because you trust the signatory?


Yes, or more specifically, because I trust the keys published by the developers are controlled only by the developers, and because I trust the developers to compile correctly.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: