SECURITY ALERT -- Remotely exploitable wine <= 2.x bugs via unencrypted plaintext HTTP intermediation

Ivan Akulinchev ivan.akulinchev at gmail.com
Thu Feb 23 13:04:15 CST 2017


Hi Michael,

> It could be discussed whether sha1 is still considered secure enough

It isn't. Google published a blog post today. [1]

Regards,
Ivan

[1] https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

On Thursday, 2 February 2017 15:45:31 CET Michael Müller wrote:
> Hello Kristian,
> 
> it is true that the download is done via HTTP, but there is a checksum
> verification using a hardcoded hash value after the download. See
> http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/appwiz.cpl/addons.c
> for more details. It could be discussed whether sha1 is still considered
> secure enough, but I think there is a reason why it was chosen. Wine is
> modular and can be built without a cryptographic library (gnutls /
> CommonCrypto) and then lacks support for TLS and most hash functions.
> SHA1 is built into Wine though. Using this method guarantees that the
> download will also work in a minimal Wine built.
> 
> Regards,
> Michael
> 
> Am 02.02.2017 um 15:00 schrieb Kristian Erik Hermansen:
> > Hello Wine Maintainers :)
> > 
> > Wine v2.x, and likely all earlier version, contain remotely
> > exploitable flaws because binaries are downloaded via insecure
> > plaintext HTTP and appear to contain insufficient signature
> > verification. This can occur when prompted to download missing files
> > such as Wine Gecko. The connection occurs over HTTP and can be
> > intermediated to compromise the client machine with a malicious
> > payload. Please advise if you are not already aware of this, when a
> > fix is planned, and if you need any additional information. Thanks :)





More information about the wine-devel mailing list