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

11–20 of 99 posts

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

#11

Post by brazzledazzle »

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…

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.

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

#12

Post by adamkruszewski »

Few years ago after not logging into Skype for few months when I have launched Skype I was logged in automatically to another person's account (similar in name to my own, but with additional prefix). It happen few times in period of 2-3 years. When I tried to report it, support staff supposedly handed the info to their supervisor and that's was it. Fortunately web client had resolved such issues.

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

#13

Post by taspeotis »

user5454 wrote: post #9

From the disclosure ( http://seclists.org/fulldisclosure/2018/Feb/33 ): > An unprivileged (local) user who is able to place UXTheme.dll or any of the other DLLs loaded by the vulnerable executable in %SystemRoot%\Temp\ gains escalation of privilege to the SYSTEM account. On my machine at least an unprivileged user does not have access to %SystemRoot%\Temp\ so it seems to be a case of what Raymond Chen refers to as "o…

I believe the default permissions for a volume grant users the ability to create folders, so they should be able to create a folder in C: called Temp and put files into it.

It’s also possible that when Skype’s updater creates the folder it has different ACLs.

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

#15

Post by cptskippy »

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.

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

#16

Post by StavrosK »

INTPenis wrote: post #7

Time to use the web client. Or not at all, I haven't had a need for skype but the last client I used was the web client on Linux.

I've had good experience with Jitsi Meet (https://meet.jit.si). You can run it from a browser, it's very pleasant and works quite well. Plus, it's open source.

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

#17

Post by Svip »

mannykannot wrote: post #10
stevekemp wrote: post #3

Earlier quoted context omitted.

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

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

#18

Post by mosselman »

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.

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

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

#20

Post by sametmax »

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…

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