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

[Michael Müller]

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 :)

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

[Ivan Akulinchev]

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 :)