Information on the revocation of WinRAR 5.91 digital certificate • Hacker News Board

Re: Information on the revocation of WinRAR 5.91 digital certificate

#151

Post by DaiPlusPlus » Fri, Aug 28, 2020, 12:00 AM UTC

AnthonyMouse wrote: post #146

DaiPlusPlus wrote: post #96

Earlier quoted context omitted.

This is why code-signing certificates must be two-factor (e.g. embedded on a PIN secured smartcard where the private-key is protected from extraction by anybody ). My Tucows certificate is still a single *.pfx file - whereas my arguably less-consequential AATL (Adobe PDF signing) certificate is stuck on a crappy USB device that requires me to install marketing-laden software for. I miss my old commodity smartcard-bas…

Doesn't actually fix it: https://www.schneier.com/essays/archives/2005/04/two-factor_... Your computer is unknowingly infected with malware, you go to do an update to your app, you insert your smartcard and enter your PIN, the malware signs the malware author's thing with it.

I understand the PIN is sent directly to the smartcard that performs the signing - not on the host PC - and it's required for each signing operation. So if malware did intercept the signature process and sign itself, I would notice that my originally intended software wasn't signed - that would hopefully be a hint to me that something was amiss and my computer was compromised.

Re: Information on the revocation of WinRAR 5.91 digital certificate

#152

Post by KiwiJohnno » Fri, Aug 28, 2020, 6:14 AM UTC

xfer wrote: post #109

olvy0 wrote: post #62

Earlier quoted context omitted.

It can extract files to paths of more than 260 characters, without any extra tools or registry hacks, on any version of windows (even xp). Winrar cannot. As a bonus, 7zip can also delete folders with file paths that are over 260 characters from its file manager ui. It has been one of the only programs to be able to do so for many years.

> paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?

To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem.

The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow.

There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.

Re: Information on the revocation of WinRAR 5.91 digital certificate

#153

Post by account42 » Fri, Aug 28, 2020, 6:59 AM UTC

DaiPlusPlus wrote: post #151

AnthonyMouse wrote: post #146

Earlier quoted context omitted.

Doesn't actually fix it: https://www.schneier.com/essays/archives/2005/04/two-factor_... Your computer is unknowingly infected with malware, you go to do an update to your app, you insert your smartcard and enter your PIN, the malware signs the malware author's thing with it.

I understand the PIN is sent directly to the smartcard that performs the signing - not on the host PC - and it's required for each signing operation. So if malware did intercept the signature process and sign itself, I would notice that my originally intended software wasn't signed - that would hopefully be a hint to me that something was amiss and my computer was compromised.

Most people would just assume there was some random error and try again.

Re: Information on the revocation of WinRAR 5.91 digital certificate

#154

Post by olvy0 » Fri, Aug 28, 2020, 5:14 PM UTC

KiwiJohnno wrote: post #152

xfer wrote: post #109

Earlier quoted context omitted.

> paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?

To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem. The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow. There are other, newer Win32 APIs for all of these that don't have that li…

You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either. Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think).

But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason.

I'm not aware of any newer APIs that can natively accept long path names, btw,

The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths. So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't...

Incidentally, the other common application which can handle long paths is git for windows.

As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines.

BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP. But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up.

[0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming...

[1] https://github.com/UweKeim/ZetaLongPaths

Re: Information on the revocation of WinRAR 5.91 digital certificate

#155

Post by batch12 » Fri, Aug 28, 2020, 9:29 PM UTC

austincheney wrote: post #118

batch12 wrote: post #73

Earlier quoted context omitted.

I agree that it would be nice to have a letsencrypt for code. The biggest hurdle I see is getting the the root trusted by OS vendors. While not impossible (the browser vendors did it), trust on these platforms may be a bigger issue since the code runs natively.

That’s less huge of a hurdle than it sounds. Root certs can be installed as part of an application installation or baked into a custom corporate OS image. Both of my employers have their certs installed in their corporate Windows images. To install the certs manually takes a bit of research. I recently wrote a Node.js script to do this in my application cross-OS using a Stackoverflow answer as a reference.

That's true, but then you don't need something like let's encrypt. If you're doing this for an environment you already control you can have your own CA. Unless you are proposing a solution where each installer for these applications bundle the root cert so only one need be installed to trust all others. That's an interesting idea.

Re: Information on the revocation of WinRAR 5.91 digital certificate

#156

Post by tgsovlerkhgsel » Sun, Aug 30, 2020, 1:56 AM UTC

The post has now been removed from the web site. Archive.org has a copy: https://web.archive.org/web/20200826113615/https://www.rarla...

Unfortunately, I can't find any update/conclusion.

However, I did find https://sectigo.com/resource-library/the-what-when-and-why-o..., where Sectigo (the CA that presumably revoked the certificate, formerly also known as Comodo) mentions a previous incident, confirms that they didn't notify the certificate owner in that incident, and promises to "review" their practices. Given that RARLAB wrote "We had not received any notification, neither before nor after the revocation", I suspect Sectigo didn't improve.