Comment by enzanki_ars | Hacker News Reader

Comment by enzanki_ars | Hacker News Reader

Parent Full thread

I must be missing something obvious here. Why can’t skype just hard code the locations and hashes of the dll files it needs to load? Why is Skype loading random DLLs from user accessible folders? I must be misunderstanding how Windows programs use DLLs and why it needs to just search for them.

Edit: @jwilk in the comments here pointed to a better article about the security vulnerability [1]. Based on the technical details, there seems to be no reason why Microsoft could not issue a very quick fix loading the DLL from the secure location.

Important quote in my eyes:

“The engineers provided me with an update on this case. They've reviewed the code and were able to reproduce the issue, but have determined that the fix will be implemented in a newer version of the product rather than a security update. The team is planning on shipping a newer version of the client, and this current version will slowly be deprecated. The installer would need a large code revision to prevent DLL injection, but all resources have been put toward development of the new client.”

In other words, it seems Microsoft/Skype doesn’t care about security at all. A couple of lines to fix the bug, in theory, but Microsoft is too busy to do it. Doesn’t make sense, unless a new version would have been released shortly, but it has been 4 months between that email and disclosure.

[1]: http://seclists.org/fulldisclosure/2018/Feb/33

> A couple of lines to fix the bug, in theory

Yes that's all it takes. No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation. None of the work on the installer or updater. No release notes or other communication to the community.

Just a couple lines of code. Easily done before morning coffee.

> No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation.

If this was a small startup, I can absolutely see those being hurdles. This is Microsoft on a product they've had for 20+ years that is a major part of their platform - those things should be mostly automated and well oiled machines.

A mature enterprise level company has no excuses for "QA is hard!" or "We can't validate patches!" for a product they sell. I don't expect them to get this out in ten minutes, but they should be able to manage a patch in 24 - 72 hours for a fairly critical and relatively easily solved security bug.

As a former Microsoft employee, my experience was that the longer a product was around, the harder it was to figure out who understood any part of it well enough to change something.

I would guess I averaged about 10 lines a month on my project that had been around for decades. Making even slight tweaks required dozens of meetings, design discussions, functional and performance testing, etc. etc. It took an eternity.

Microsoft is still actively patching Skype. Here's an example of them patching what sounds like a similar DLL flaw just last year:

https://www.cvedetails.com/cve/CVE-2017-6517/

And don't forget that the product work as expected in most cases and many changes are not justified.

The bike shed won't get painted to a new color just because a the new middle manager asked for it.

Ironically I would comment exactly what you did with, but the roles reversed:

“If this was a small startup I couldn’t see those being hurdles but at a behemoth like MS with an almost 2 decade old product I can.”

I feel like you've got those reversed. In small startup the bug fix would be deployed to production before it's committed to source control.

In a large enterprise the process isn't too hard, it's just complicated.

I was neither justifying or admonishing MS for this issue, I was just responding to a gross trivialization of the process that I found offensive.

> 24 - 72 hours for a fairly critical and relatively easily solved security bug

Let's see. How many microsoft employees would it take to change a lightbulb? ;-)

https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...

Highlight:

> That initial five minutes of dev time translates into many person-weeks of work and enormous costs

This is just to add an interesting article on top of the sibling comment from the MS employee; nothing's easy in the engineering of a large product.

I'm guessing if they fix this bug the simple way they break the entire product and the proper way is many months of work (entire eco-system restructure).

> code reviews, security review, integration testing, quality assurance testing, compatibility testing,

Valid counter-criticism of the "just a couple of lines of code" line generally, but four months is a long time since disclosure and that is a lot of morning coffees.

I wasn't defending Microsoft, just responding to the trivialization the op made.

According to the article, Microsoft is dedicating resources to a new client which won't exhibit the flaw.

So I guess that means either they examined the flaw and determined it wasn't a high enough risk to warrant patching, or they don't care. Dealer's choice I guess.

Maybe the number of people using Skype these days is insignificant? I tried to use it about a year ago and noped the hell away after 5 minutes.

As others have already noted, yes, it’s a pain ship fixes in a company setting, and I fully understand that. On the oth r hand, 4 months for no fix is inexcusable.

I think this is a response to the headline, which specifically mentions a "massive code rewrite".

Luckily 'they don't care about security at all'. They just looked into it for fun when the report came in.

"Can't you just..."

Like nails on a chalkboard.

Bureaucracy is hard, but so is losing clients or getting sued by an enterprise customer for negligence in handling a known security hole in a timely fashion. Corporations can become extremely agile when there's money on the line.

I enjoyed your retort, but I'll note that it being "just a couple lines of code" at least should imply that this is no harder than other security fixes, which somehow do make their way out faster than main releases.

This is due to the way that Windows loads DLLs, there is a defined search order and the current working-directory is one of the locations.

There have been a lot of write-ups on this topic on Raymond Chen's blog, here is a good example:

https://blogs.msdn.microsoft.com/oldnewthing/20101110-00/

If that were all there is to it, would this not be an issue for all Windows applications, not just Skype? Is it just Skype that puts the current working directory in the list, or at least in a position where it can be used to preempt the loading of the correct DLL?

The link you provide as an example suggests that this sort of thing might be done to facilitate testing, but again, that doesn't seem to be a compelling reason for not fixing it now - 'ship what you test' is a good principle, but it does not preempt 'fix known security holes.'

It is an issue for all Windows applications.

There was a month when 50%+ of the traffic on full-disclosure@ was just one person repeatedly announcing newly discovered problems with various Windows software that all involved search-path problems ("DLL hijacking" or related issues).

There's at least one author who is super keen on using the phrase "binary planting" to refer to a similar class of attacks.

Well, I guess not all Windows applications are run as the SYSTEM account, but the Skype SKY-tmp is? I'd assume, at least, that programs intended to run as the SYSTEM account does a better job of loading DLLs from secure locations.

In other words, the Linux equivalent would be a setuid executable that doesn't properly ignore LD_PRELOAD_PATH.

Well, the system executable should not be run as root from /tmp obviously.

Its an issue with all windows applications but not all windows applications have the same elevated permissions that skype seems to

That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

I was just about to come back here and mention that. The article and comments that @stevekemp linked to provided a lot of insight, but as you mentioned, there are ways to prevent exploits of that nature, which the comments in the article point to also. Something still seems to be missing from my understanding of what Skype is doing...

The cynic in me thinks this is already known and is in use by a "strategic partner" as a vector. The next version will only make it harder to find and exploit.

Your comment reminded me of this: https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac...

I doubt this was intentional at first, but the fact that they don't want to fix it is very fishy.

That is a very different issue, as there the concept is that the original file in the original location is being replaced. As is stated in that post, at that point the person could just as easily replace the program itself with a modified version of the entire program. That is not a security issue in the software.

You can actually control most of this using an application manifest. The advantage being you can prevent any non-"known" dll from loading from any folder it's not supposed to. Moreover you can ensure that it's embedded in the binary so if someone tries to modify the manifest it breaks the cryptographic signature on the binary.

To anyone going "but what if they replace the binary!" well then they've already gotten past the air-tight hatchway.

It would be interesting to see Google Project Zero’s take on it. It’s a shame they didn’t discover it because I’m sure the back and forth between them and the Skype devs would have been really interesting.

PZ almost certainly is aware of at least the general issue - Windows DDL hijacking posts hit the Full Disclosure list pretty much weekly. It is a very well-known issue, at least among those who subscribe to security lists, approaching dead-horse status.

> Why is Skype loading random DLLs from user accessible folders?

Good question. Almost every time I want to use some new security tool - like say AppLocker - Skype craps out on me, because it seems to be so badly programmed, and it's all over the place in Windows. It's why I stopped using the native app completely, and only use the web version whenever I still need to use Skype.

> Why is Skype loading random DLLs from user accessible folders?

%SYSTEMROOT%/Temp doesn't seem to be user-readable at all, so I'm having trouble understanding how you write anything there without already having escalated permissions.

I need to test this later as I only have access to an unprivileged account at the moment, but based on comments online (https://stackoverflow.com/a/11917816), the folder is write only for unprivileged users (FILE_ADD_FILE).

You're correct, I was able to write a file without privilege escalation, and then I verified it was there by escalating. Thanks.

If anyone is wondering, it's a little bit tricky to check because without the read permission, Windows Explorer can't see what the permissions are.

More probably this is something they need for a reason we don't know about but won't disclose.

Reply on news.ycombinator.com