Windows 10 and the OneDrive vulnerabilities – Part 3

[German]In Part 1 and Part 2 of my article series I described the vulnerabilities in Microsoft's OneDrive client (addressing the location of program files in the unprotected profile folder and the use of outdated open source libraries with known vulnerabilities). In part 3 I try to give an explanation for that behavior and there is a statement from Microsoft.

A possible explanation?

During writing about Qt5 in part 2, I came about an explanation, why the developers designed it this way (and also explains other issues already mentioned in Part 1 and Part 2): It's Mr. Satya Nadella's previous credo 'Mobile first, Cloud first' – Windows doesn't matter anymore, but somehow should not die.

The development of software should be designed in such a way that products like Office, a OneDrive client (if necessary as app) etc. has to run on different platforms! So the developers of the OneDrive client fell for the idea of using the Qt5 library in addition to OpenSSL. According to Wikipedia:

Qt is a cross-platform application framework and widget toolkit for creating classic and embedded graphical user interfaces, and applications that run on various software and hardware platforms with little or no change in the underlying codebase, while still being a native application with native capabilities and speed.

And Android, iOS, macOS or Linux do not have a Windows crypto API etc. In order not to rewrite code for each platform, they use tools to create cross-platform software. The result looks like 'not fish, nor meat'.

For me, this also explains some steps within the development of the OneDrive client since Windows 8.1. There has been several times where they re-started the OneDrive client development. Suddenly, functions that the previous OneDrive client could do very well had disappeared.

Well, that's settled, so there's (probably) a reason for this stuff. But at this point you have to say goodbye to the romantic idea that Redmond is still programming for Windows 10. Microsoft's developers are cobbling together their software for various platforms – and the result is accordingly.

And at this point it may be obvious that the OneDrive for Business Client is sailing in the same waters. Stefan Kanthak also says that dropbox is by no means better.

Furthermore, I let Stefan Kanthak read the text in advance. His feedback on the subject:

everything Qt can do (according to WikiPedia) has been provided by the Win32 API since over 25 years.

It doesn't make sense, to use Qt5 for a client, that is only available in Windows, it's superfluous: there is no OneDrive client for Android or iOS or Linux.

Well, for Linux there is no client from Microsoft, but there are OneDrive apps for Android and iOS I would say, that are clients. What Kanthak also criticise however, is this:

Also on Windows with its rich Win32 API, more and more developers who seem to be too lazy to deal with the Win32 API are abusing libraries/ components like Boost, Qt ,… which are completely superfluous there.

The initial problem (lack of knowledge about or mastery of the Win32 API) then splits into two: the superfluous components used by the developers are NOT updated. Using OpenSSL or Qt5 under Windows is a pain in the ass!

This OpenSource crap again has many dependencies on "tools" like CMake, Python/Perl, or on an history MS compiler for MS-DOS,

That's what Microsoft says about the OneDrive client

In this series of articles I have uncovered some vulnerabilities in the OneDrive client to which Stefan Kanthak has drawn my attention. And I tried to find a logical explanation for Microsoft's design decisions. However, I have no feedback from Microsoft whether my above conclusions are correct – so it remains a working hypothesis.

However, security specialist Stefan Kanthak informed Microsoft and its Security Response Team (MSRT) about the vulnerabilities in the current implementation of OneDrive. Kanthak send me a copy of the mail exchange with Microsoft, which I cite below in excerpts.

In mid-July 2018, Stefan Kanthak drew the attention of the MSRT to the security issues (he basically described what I documented in Part 1 and Part 2). Microsoft replied as follows:

Thank you very much for your report.

I have opened case 46989 and the case manager, Kamuran will be in touch when there is more information.

In the meantime, to protect the ecosystem, we ask that you respect coordinated vulnerability disclosure (see here for details) and not report this publicly before we have notified you that this issue is fixed.

So a case has been opened at Microsoft and they ask not to publish the reported vulnerability until it is fixed. Well, it's a standard phrase. But a few weeks later there was the following answer:

From: "Microsoft Security Response Center" <secure@microsoft.com>
To: "Microsoft Security Response Center" <secure@microsoft.com>; "Stefan Kanthak" <******>
Sent: Wednesday, August 08, 2018 2:09 AM
Subject: RE: ?MSRC Case 46989? CRM:0461058631

> Hello Stefan,
> Thank you again for submitting this issue to Microsoft. We determined that a fix for this issue will be considered in a future version of this product or service.

At this time, we will not be providing ongoing updates of the status of the fix for this issue, and we have closed this case.

Thank you very much for working with us.
> Regards,
> Kamuran
> MSRC

In a nutshell: Following the internal guidelines (see Microsoft Security Servicing Commitments) they decided, that vulnerabilities do not require an immediate fix. But they intend to address the issue sometime in the future and closes the case.

My 2 Cents

It has now become now an article series consisting of three parts. I've described things in a broader manner, so that blog readers can understand and classify the vulnerabilities. So you may judge yourself as a reader. For me, however, this story has a different dimension and when I was writing, some things suddenly became clear to me.

I still have had the idea 'Windows 10 has a solid basis, here and there a few adjustments/modifications, then it fits, Microsoft just has to decide that'. I think about auto-updates, semi annual feature updates controllable and disable as well as making a basic operating system with configurable additional Windows functions by means of de-selectable features.

This naive idea I put down the last weeks. The more I deal with certain aspects of Windows 10 development and implementation of various features under stability and security aspects (as a blogger I often just scratch the surface), the clearer it becomes for me: This development is currently going down the hill.

Why should they work more solidly on the core of Windows 10 than with the tweaked OneDrive client? The many 'exceptions' in the Windows update environment (keyword: besides Windows Update there are other mechanisms like USOclient, Remsh etc.), to download and install updates), the problems with patches or the many bugs in new features and after release of a feature update draws a fatal image: The development of Windows 10 is no longer stable and it seems that 'they' lost control.

I just read a nice article Das Problem mit der Agilität (unfortunately in German) by Eberhard Wolff, which deals with Continuous Architecture. He outlines what is behind the term Agile software development and reports on his practical experience. There was another piece in my mosaic, as Microsoft has recently also been using the term agility or continuous delivery in the Windows 10 and Office 365 development environment.

The question remains whether you can and should use agile development and continuous delivery for a platform like Windows 10 (or at least the basic operating system)?.Maybe the whole approach isn't helpful for Windows development, where we depend on a a core OS solid as a rock (and won't see disruptive agile 'not ready yet' prototype development). What do you think?

Articles:
Windows 10 and the OneDrive vulnerabilities – Part 1
Windows 10 and the OneDrive vulnerabilities – Part 2
Windows 10 and the OneDrive vulnerabilities – Part 3

Similar articles
Security-Risk: Avoid 7-Zip
7-Zip vulnerable – update to version 18.01