About Wine Security
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I'm coming to you after a short discussion with Alexandre on this topic. Wine gets more and more used, in various ways: either directly by users, or because it gets shipped in various form. It can packaged in a distribution, forked to suit a project needs (thinking about pipelight), or even shipped along with software to save native portage costs. Not to say that it's core of the ReactOS operating system itself. But as any other software, Wine can present security vulnerabilities. MITRE exposes some of the code defects pattern (known as CWE) that can lead to potential exploitation and thus to security vulnerabilities [1]. When such defect is found and looks potentially exploitable (either because a crash was reported, or because it directly deals with callers data), a vulnerability ID (CVE) can be assigned by MITRE to reference the potential security vulnerability and make it known to people using it. Some of them (buffer overflow, overrun, double-free, use-after-free, and so on) are sometimes found and fixed in Wine without further consideration regarding what it would imply for real Wine (mis-)usage. Even if no Proof of Concept is available at the time when the commit is made, it doesn't mean it cannot be exploited later on. With such exploits, it generally means that the attacker can target a Linux OS through a crafted PE binary. What I'm proposing here is that I start requesting CVE-ID for these findings when I find them in the commit logs of Wine and that they look exploitable. My hope is that it would allow distributions to repackage Wine taking care of these issues, but also to make people shipping Wine aware that the Wine they are shipping is likely vulnerable. This proposal it though limited in space & time: I wouldn't only do it starting in 2015 (I don't believe going backwards would make that much sense) and for 1.7 branch which is, I believe, the most used. I'm looking for your feedback on my proposal and how you believe such vulnerabilities in Wine can affect the host Linux (or Mac). This wouldn't involve more work on your side (excepted if I ask for more details to make sure I'm right in my analysis of the issue). With my best regards, [1]: https://cwe.mitre.org/ - -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUrVTCAAoJEHVFVWw9WFsLPDgQAILhixxtba3y2qadCl+2dBWg 1v2qjsUouAJe7vq28tx63MNK0Tm6ykHB66SJuWWUTMwYAHIz+Uzr2PJMHCq0aZs+ dnGo4sTycEkuMNVC/i9zijJtCd7/r5v+VJBQNji1lVhwY+ZLsA8mlp+UKb9fjos6 wwMk+5lCsiqvPubKvVZ8qfXKD2xEBkjWu15JmivR6ZhaNm5vDXmNxtqVT590JowW WWmcn6GiWMQQgAj6CLzG9d8qaHiJiuNmHi0BtUPZ8e+9hfcl76DBMiy1L8M3PM0f 1YRWF1NMOTQOr6nqxuviPL5eO7DKUmsiNVK1KGnNXMbjf/8EwL03VobAFaPu0X55 6v3jcNdBq9NCcRpkzUVksSMOSlzj4S8lvLEFYY8mWYW/o3TfmdTbLqeO7UIVJJiP lx1Pth7WA03wqzvhm5+/sIavkDDn3Z6/TY9k0BVHzq3VahUx6TP59mYPjI9jUvwA /0HoCCaD6AcGnDf8fsTNkLgqtqD6s3iOMra0mpH7nUQoTUds82ehZXRJ4viWsHxj c0mfAy/3ct8uMZAbVwjnahrk/RrF6DzI3eKh/LI5l5rQ9COgPwE2Ij2IWnPRK2zv XJbG161RRQwZSSU8TeBr2I/OxxQ+VE2Z0E4xSZY4tjYhdk/i9Y32J9w68qquISlF 4wtw5d9I9DFwvxq/AnBV =auVK -----END PGP SIGNATURE-----
On Wed, Jan 07, 2015 at 04:46:10PM +0100, Pierre Schweitzer wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear all,
I'm coming to you after a short discussion with Alexandre on this topic.
Wine gets more and more used, in various ways: either directly by users, or because it gets shipped in various form. It can packaged in a distribution, forked to suit a project needs (thinking about pipelight), or even shipped along with software to save native portage costs. Not to say that it's core of the ReactOS operating system itself.
But as any other software, Wine can present security vulnerabilities. MITRE exposes some of the code defects pattern (known as CWE) that can lead to potential exploitation and thus to security vulnerabilities [1]. When such defect is found and looks potentially exploitable (either because a crash was reported, or because it directly deals with callers data), a vulnerability ID (CVE) can be assigned by MITRE to reference the potential security vulnerability and make it known to people using it.
Some of them (buffer overflow, overrun, double-free, use-after-free, and so on) are sometimes found and fixed in Wine without further consideration regarding what it would imply for real Wine (mis-)usage. Even if no Proof of Concept is available at the time when the commit is made, it doesn't mean it cannot be exploited later on. With such exploits, it generally means that the attacker can target a Linux OS through a crafted PE binary.
What I'm proposing here is that I start requesting CVE-ID for these findings when I find them in the commit logs of Wine and that they look exploitable. My hope is that it would allow distributions to repackage Wine taking care of these issues, but also to make people shipping Wine aware that the Wine they are shipping is likely vulnerable. This proposal it though limited in space & time: I wouldn't only do it starting in 2015 (I don't believe going backwards would make that much sense) and for 1.7 branch which is, I believe, the most used.
I'm looking for your feedback on my proposal and how you believe such vulnerabilities in Wine can affect the host Linux (or Mac). This wouldn't involve more work on your side (excepted if I ask for more details to make sure I'm right in my analysis of the issue).
I would say that exploiting by "crafted PE binary" is not in scope for CVE allocation for Wine, as you would not keep the crafted PE binary from doing "int 0x80" itself. (Except of course when the binary crashes already the loader or imagehlp or so.) But bugs in progressing any data leading to exploitation would be. This is probably going to be tedious ;) Ciao, Marcus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2015 17:19, Marcus Meissner wrote:
On Wed, Jan 07, 2015 at 04:46:10PM +0100, Pierre Schweitzer wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear all,
I'm coming to you after a short discussion with Alexandre on this topic.
Wine gets more and more used, in various ways: either directly by users, or because it gets shipped in various form. It can packaged in a distribution, forked to suit a project needs (thinking about pipelight), or even shipped along with software to save native portage costs. Not to say that it's core of the ReactOS operating system itself.
But as any other software, Wine can present security vulnerabilities. MITRE exposes some of the code defects pattern (known as CWE) that can lead to potential exploitation and thus to security vulnerabilities [1]. When such defect is found and looks potentially exploitable (either because a crash was reported, or because it directly deals with callers data), a vulnerability ID (CVE) can be assigned by MITRE to reference the potential security vulnerability and make it known to people using it.
Some of them (buffer overflow, overrun, double-free, use-after-free, and so on) are sometimes found and fixed in Wine without further consideration regarding what it would imply for real Wine (mis-)usage. Even if no Proof of Concept is available at the time when the commit is made, it doesn't mean it cannot be exploited later on. With such exploits, it generally means that the attacker can target a Linux OS through a crafted PE binary.
What I'm proposing here is that I start requesting CVE-ID for these findings when I find them in the commit logs of Wine and that they look exploitable. My hope is that it would allow distributions to repackage Wine taking care of these issues, but also to make people shipping Wine aware that the Wine they are shipping is likely vulnerable. This proposal it though limited in space & time: I wouldn't only do it starting in 2015 (I don't believe going backwards would make that much sense) and for 1.7 branch which is, I believe, the most used.
I'm looking for your feedback on my proposal and how you believe such vulnerabilities in Wine can affect the host Linux (or Mac). This wouldn't involve more work on your side (excepted if I ask for more details to make sure I'm right in my analysis of the issue).
I would say that exploiting by "crafted PE binary" is not in scope for CVE allocation for Wine, as you would not keep the crafted PE binary from doing "int 0x80" itself.
Well, by crafted PE binary, I mean, binary that would be designed to exploit such weaknesses. To corrupt memory, read from it or whatever.
(Except of course when the binary crashes already the loader or imagehlp or so.)
That's my point.
But bugs in progressing any data leading to exploitation would be.
This is probably going to be tedious ;)
This generally is, but helps a lot, so... It deserves it, I believe.
Ciao, Marcus
- -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUrWErAAoJEHVFVWw9WFsLSQEP/AkOoeIQPdFa3s9OXzxlc0K+ +uJBIgTHiz/fDkzv4mT8zoJ21y+QEx8P2mDhYIj6LnVQZk9Wk1SZN14PJlCFA5A2 le5FMPrfbjHxqH2FeuyCfJ12Q5vsGh8y43DWpYB4rqt4+oYHrG3ieTUHtbCBG5Z3 2o2w82CSYS6DzwFYqLxbpUnj9iAVdlnQNCwE9Ru9MstkZsAv1VqJbpbaBjsU78He AnxanUGFV3FWQiv2Tx2PjLJbR2BuNbmyDpwyZ3wCTlPHzj5uHyp2C5Cg9xZQWOmU pLWHcxrPRyazO8EIsvCYNvollT3cCVrHrdryw9VPcjANihRrtMOGy7GwbJNsyT1z H2T32kCON0ybKavkr9nIiLG+getoiGH34Hq2ybRWl/Y6Tk6OQY1+dMQXyNBgh317 VHQ4C9RKcOLzRTq3+t7uNluCKV06tZV6YVX5C9/aMLqvvmnQrvtJY/9iP0+kZzl0 EiEfPmYm7KxVSODUEB/r3/yGm4oERadlEVWuQE7rhYj/BuSbFR3OS+ydeI1kliJT SBj6nCndGm/VL18UvhKdBRB5SFsTErehAMkqFf/52jrQVPFtcdSwxSYPFwnClNtZ pXyfPBOfmiFkOfDFM1FmqM/HEKiqb/9Q1xPMXj6eVCpVuji9nLelSxgey2dFM8UI uFsGUYez9+1eFh6UGo31 =Obcw -----END PGP SIGNATURE-----
Pierre Schweitzer <pierre(a)reactos.org> writes:
On 07/01/2015 17:19, Marcus Meissner wrote:
I would say that exploiting by "crafted PE binary" is not in scope for CVE allocation for Wine, as you would not keep the crafted PE binary from doing "int 0x80" itself.
Well, by crafted PE binary, I mean, binary that would be designed to exploit such weaknesses. To corrupt memory, read from it or whatever.
That's the sort of thing I was alluding to in our private discussion. In the context of Wine, postulating a specially crafted binary doesn't make sense. Obviously such a binary doesn't need to exploit Wine to do anything it wants. -- Alexandre Julliard julliard(a)winehq.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2015 21:19, Alexandre Julliard wrote:
Pierre Schweitzer <pierre(a)reactos.org> writes:
On 07/01/2015 17:19, Marcus Meissner wrote:
I would say that exploiting by "crafted PE binary" is not in scope for CVE allocation for Wine, as you would not keep the crafted PE binary from doing "int 0x80" itself.
Well, by crafted PE binary, I mean, binary that would be designed to exploit such weaknesses. To corrupt memory, read from it or whatever.
That's the sort of thing I was alluding to in our private discussion. In the context of Wine, postulating a specially crafted binary doesn't make sense. Obviously such a binary doesn't need to exploit Wine to do anything it wants.
Likely my 'crafted' word was poorly chosen. Here, I refer to a binary designed to exploit the flaws in Wine, as it would be designed to exploit flaws in any library. The user excepts to run a sane binary, whereas said binary will actually use its running context to corrupt memory, attempt to cause a denial of service in Wine, and so on. As for any other exploit (be it for a lib or another tool). Cheers, - -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUrZ14AAoJEHVFVWw9WFsLHkQP/if7LKib0C3J0l4BxFdFSbZu dOEYexCwN1eUQtdkU6g0fsYqE31Igo2Ndn7Ss8GyXYLzNe2pcOXUHIrXapenPEnr p+gIRsqKWVIu6zf5QxKf7Lr0qcsoLbo2uJIJU/FiTfHhFOj6cLP7kxmkY6LwXeUM uh1kDZOO+a+HVkEbGaxByXIbElPgy8N9BW+iXD4bQTjwYSZ22efWQLgPIgVbJqc4 x0tcIHZ9F7cHWgVotgOXdtNzOQ1QRXLd15Rgcw4gjA3NQnry3WkProcO3WF8hpzq qg3Ew/OSD9DrvtOIAxRz+U8iF1wQD2DLBrC/9+Q2fAygqZz/pe1IAhTLlUw4kr2H dKhpGHhWSTKcd265SIzmJXHyuN3UUJurk8Fjt48QoRJ2uyX/p3m2U7VXw5tnK2rt yFkTB9aa5es73oGg6puUtaJFb/54HDukdWzj6xNaYappnnk48bdd9cvgfTe7BTV+ Pug/TIL/mHor/C7z0i3yHQN7X1aiGKJQyVKOa1VXz7I7MJwu8iNQeRsklSKPW0Am bz5lHCCS3pXp55mxXPhOxU8OtzLl9/FEsT5u1nMRsKZ7i7wpR37tXKuStUQ3LmIH 20gynP9NZs9QBx0BOxxfQ+3VCVwUo1M+RuWuWW1+vONYejcvRAWRRmMItmsW6m/j qAUakjVaElbvBRDu7gYL =SDqC -----END PGP SIGNATURE-----
On Wed, Jan 7, 2015 at 2:56 PM, Pierre Schweitzer <pierre(a)reactos.org> wrote:
Likely my 'crafted' word was poorly chosen. Here, I refer to a binary designed to exploit the flaws in Wine, as it would be designed to exploit flaws in any library. The user excepts to run a sane binary, whereas said binary will actually use its running context to corrupt memory, attempt to cause a denial of service in Wine, and so on. As for any other exploit (be it for a lib or another tool).
Typically, flaws in a library don't allow a program using the library to do anything it couldn't do without access to that flaw. The exception would be something like polkit which has privileged components compared to the software using it. All of Wine's components run as a single user, so flaws in them cannot be exploited in this way. I think we would be more worried about a scenario where a flaw in Wine creates vulnerabilities in programs running in Wine. An example would be if one of our image processing functions corrupted memory when given some invalid data. This could be demonstrated using a test program that reads an image using the Windows API, combined with crafted image data that exploits the flaw. The test program does not have to be designed to exploit a flaw, in fact the problem is that it was designed to do something sane (read and display an image), but an attacker supplying the image file can make it do something else. (Sorry if you already know all this, it's unclear based on what you've said.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/2015 22:25, Vincent Povirk wrote:
On Wed, Jan 7, 2015 at 2:56 PM, Pierre Schweitzer <pierre(a)reactos.org> wrote:
Likely my 'crafted' word was poorly chosen. Here, I refer to a binary designed to exploit the flaws in Wine, as it would be designed to exploit flaws in any library. The user excepts to run a sane binary, whereas said binary will actually use its running context to corrupt memory, attempt to cause a denial of service in Wine, and so on. As for any other exploit (be it for a lib or another tool).
Typically, flaws in a library don't allow a program using the library to do anything it couldn't do without access to that flaw. The exception would be something like polkit which has privileged components compared to the software using it.
Depends. We can think about other scenario. Vulnerability in an API a network application is using, which allows leaking data over the network. Or to run another program remotely. Or bypass security checks and execute parts it shouldn't. Even if this doesn't elevate privileges, it can already harm. Not talking about crashing the whole Wine instance.
All of Wine's components run as a single user, so flaws in them cannot be exploited in this way.
I think we would be more worried about a scenario where a flaw in Wine creates vulnerabilities in programs running in Wine. An example would be if one of our image processing functions corrupted memory when given some invalid data. This could be demonstrated using a test program that reads an image using the Windows API, combined with crafted image data that exploits the flaw.
Yup, sorry, forgot to speak about that one, which is also often tracked. That can even go farther. Crafted images or input for a program can lead to severe damages, or running programs (cf: CVE-2014-7209).
The test program does not have to be designed to exploit a flaw, in fact the problem is that it was designed to do something sane (read and display an image), but an attacker supplying the image file can make it do something else.
(Sorry if you already know all this, it's unclear based on what you've said.)
Thanks for it. I would have totally forgotten to speak about it otherwise! Cheers, - -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUrlEmAAoJEHVFVWw9WFsLJk4P/2HWr15ZK47K2EvDPUY6SMJm Y8icgSpX1Ms2YEWnqhA2QCKilQDgcdrUW56iHl6LLTIWESNL5BXbXYyxmJR1LXoD 0cT+dHpXscG8QQss4bA6PUP7zx7Il2gp/Ytf2/t/6hjESZ3lSXohskXBT/ET9iRN SLcfjU1RW/kBGPTCMfgkckx5OXHQmMQIXK/Vyddm6gBcKMA0FXBQdEOQpCy7tmre QniEPRvoRLDZhWllDAcWlMBvTcy/aYIBQeaMsbsLgWNRpMfQ13g+yPyhxTP5gNRw g0opsa/47XX5ehaWhA0QGQWOSsUvqaFQzXkIOhcZLz2/W98dAwb+e17M9ZTQ0h/I qmkC2vFe9pNOC274/LjfkZaHkM1fKDmgloi1RwueuxPbkoIBFnbRkbqpiHcuptAQ sH8YXm3vlY8ee9EfQiRm5cJMsys2DOkEKcfD7SDqqEv3KgG5KhR40qzgsgH0IjXZ TF72/sRnP9hQ+VkpwFYmiBcBYtOX/szUeebWC2f2vKfIds8MjDq3GZSt9h88bUFO bcc9eU8tk5oEtmWiYpL8RV9zL7CLkZcLJphDLBp3L3Yy/fIj8KSVQIZub55G+yf4 IYuDnHoA7lBbFkXV3Q3fkYQYyl/1+xRuJnxlv48UJjB+hld45NFbqqhA80b449Do Oi4ifPoGazTCZlBf7fxS =6xES -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-01-07 um 21:19 schrieb Alexandre Julliard:
That's the sort of thing I was alluding to in our private discussion. In the context of Wine, postulating a specially crafted binary doesn't make sense. Obviously such a binary doesn't need to exploit Wine to do anything it wants. PE parsing may be an exception though. A specially crafted PE binary could try to execute code when e.g. the file selection dialog wants to extract its icon. Microsoft had a related problem on Windows a while ago: http://blogs.msdn.com/b/oldnewthing/archive/2011/06/09/10172702.aspx
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUrkW1AAoJEN0/YqbEcdMwGlEQAIrKz9qxSZnCZ8vFPWzNeMQw 6zb2A8BTNmWYrb1APzcdYwW94Y2YCitKPqN3MdGXcmq7eE/yP31eVRRbhU2pMQgn d/7YrY2tQiHT62qP1NuYOKV+Q+duaMERgxHSq0xcKw2hP4EeH013ROJfSOnGHDbz /L1xdmm8SlE11CXznc722mUUYGD6xb2GXIW7CpENrxuRI+5+aNlQQJAzT66nLoog 9z9z9oYJEYTvJZce/RYMEjZsv78TCSODxSVHdQ/qTj/7iyLtqES2feXnOmsLTo+0 6izKQOM5DHQdLWk7pKXDSHOT9Hmd1Pg8n2zRJki+y/Iq4zZzOUAm2T4SItiGFm+j UXA8klP7rxe2mn4Bt76FbdEMQRsFmpE0KGUJ3CJqHsHIhPY2saRw6wQVX/8Z675N TlvxfNeu1c9sIcdY6DIUh9wPP5omdYHW5O6xfQKte5yC+52mLHuo8pj0OqRKR3Ma Bx1P4mzom3+UV2AB0HyeRB7VQQSTuQDrREPse2UawzSoco+nrIzh3Z19yjZweryO frmjs3uAbHgn++ivOSIoGxn/khKSO8yqht5McXW2gozgUw0g25STBP3GeYTgC3Ik coSwg3+Sseen6560OAmV4s3I6Tf44dnDA4sfyi7LFdOPQg10F8eHHkWmwjo6aBi/ LqYbLLkwArp5galSUpwc =msbx -----END PGP SIGNATURE-----
participants (5)
-
Alexandre Julliard -
Marcus Meissner -
Pierre Schweitzer -
Stefan Dösinger -
Vincent Povirk