Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skype can't fix a nasty security bug without a massive code rewrite

zdnet.com

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Skype can't fix a nasty security bug without a massive code rewrite

#61

Post by cptskippy »

vorpalhex wrote: post #28
cptskippy wrote: post #15

Earlier quoted context omitted.

> 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…

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.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#62

Post by cptskippy »

dspillett wrote: post #22
cptskippy wrote: post #15

Earlier quoted context omitted.

> 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.

> 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.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#63

Post by notriddle »

Svip wrote: post #17
mannykannot wrote: post #10

Earlier quoted context omitted.

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 r…

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.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#65

Post by corporatocracy »

cptskippy wrote: post #15
enzanki_ars wrote: post #2

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 de…

> 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.

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.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#66

Post by jmull »

The title isn't quite right here.

It's not that Microsoft can't fix this bug without a massive rewrite. It's that they'd rather do the massive rewrite than fix this security bug in the current client.

They could put a small amount of resources on critical fixes for the current client. It would have a small effect on the release of the new client but put them in a much better position once the new client is ready in terms of how many users they retain and how happy those users are. Overall, there's a lot of bang for the buck for this in terms of the overall health of the product.

Now, Microsoft may very well have a critical fix effort for the current client but this bug didn't make the grade as a critical bug. (I can't tell from just this article whether I would consider this a critical issue or not.)

Re: Skype can't fix a nasty security bug without a massive code rewrite

#67

Post by leeter »

stevekemp wrote: post #3
enzanki_ars wrote: post #2

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 de…

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/

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.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#68

Post by cptskippy »

sodapopcan wrote: post #56
cptskippy wrote: post #15

Earlier quoted context omitted.

> 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.

"Can't you just..."

Like nails on a chalkboard.

Re: Skype can't fix a nasty security bug without a massive code rewrite

#69

Post by korethr »

The article mentions that this vulnerability affects Mac and Linux too. I'm curious how that's the case. DLLs, as i understand, are the Windows equivalent of shared libraries on Unix-like systems. Even if that's the case, there'd have to be subtle but important differences in the implantation details, due to the differing heritage of both systems, wouldn't there?

I've heard about DLL-injection many a time, for purposes ranging from benign (fun Counter-Strike mod) to evil (I am now NT AUTHORITY\SYSTEM, bitches). I've not heard about .so injection on Unix-like systems. Why is that? Is it because implementation details of Unix shared libraries preclude them being used in the same or a similar way, that I've just not been on the right mailing lists to hear about it, or more nobody cares to bother because everyone's on Windows?

Those of you whom are familiar with either or both systems, what material would you recommend for study that would answer my questions, or help me understand enough to ask a smarter one?

Re: Skype can't fix a nasty security bug without a massive code rewrite

#70

Post by cesarb »

korethr wrote: post #69

The article mentions that this vulnerability affects Mac and Linux too. I'm curious how that's the case. DLLs, as i understand, are the Windows equivalent of shared libraries on Unix-like systems. Even if that's the case, there'd have to be subtle but important differences in the implantation details, due to the differing heritage of both systems, wouldn't there? I've heard about DLL-injection many a time, for purpos…

On Windows, for legacy compatibility reasons, the default DLL search path includes the directory the executable is located on by default. On Unix, that's not the case.

I'd recommend the following study material:

- Windows: "Dynamic-Link Library Search Order" https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

- Linux: http://man7.org/linux/man-pages/man8/ld.so.8.html

Post reply on HN