Boffin suggests Trappist monk approach for Spectre-Meltdown-grade processor flaws, other security holes: Don't say anything public – zip it

Prof asks: What good comes from letting everyone know a vulnerability exists?

Woman telling you to be quiet

A computer engineering professor has an interesting idea for how to handle the public disclosure of serious vulnerabilities: don't.

Professor Gus Uht, engineering professor-in-residence at the University of Rhode Island, USA, argues that everyone would be safer if those who discover serious vulnerabilities refrain from revealing the details to the public, allowing the flaws to be secretly fixed by vendors and developers, and updates pushed out before anyone crafts suitable exploits to hack victims.

The discovered security blunders would thus be privately reported, and kept under wraps until someone actually exploits them in the wild, at which point people can be alerted to make sure they've installed the necessary and available patches. In effect, Prof Uht fears disclosing details of weaknesses within software and hardware too soon gives crooks a chance to build exploit code and go on the offensive. We'd argue that publicity draws attention to the need to patch and protect, but what do we know?

"The norm today is to fully disclose vulnerabilities, most often following the tenets of responsible disclosure," Prof Uht wrote in an editorial for ACM Sigarch at the end of January. "It is our view that this is not the best thing to do since it effectively broadcasts weaknesses, and thus aids and abets black hat hackers as to the best ways to compromise systems.

"With the complexity of current hardware and software systems arising from billions of transistors and millions of lines of code, it is unlikely that any system will ever be bug-free or vulnerability-free. There are effectively an infinite number of unknown vulnerabilities ... What then is the point of actively ‘discovering’ new vulnerabilities and disclosing them? They are effectively being invented and empower black hats to wreak havoc without making systems safer. It is a race to the bottom. At the same time it can unnecessarily ratchet up the public’s anxieties."


In case you're not already sick of Spectre... Boffins demo Speculator tool for sniffing out data-leaking CPU holes


Uht points at last year's disclosure of the Spectre and Meltdown CPU side-channel vulnerabilities as an instance where everyone would have been better off had a lid been kept on the flaws while the semiconductor industry worked to adjust their designs and slip out new chips and software mitigations.

For what it's worth, The Register was first to report the concrete existence of the speculative-execution bugs in modern CPUs in early 2018. Google and others went public with details of the flaws within days, and months of patching and code updates to secure affected processors followed. Intel, AMD, Arm, Microsoft, Red Hat, and other organizations, had privately known about the issues for months, and were working throughout the Fall and Christmas on software and microcode-level mitigations, aiming to release them in time for Windows' January Patch Tuesday.

The professor suggests that the side-channel flaws were so obscure and difficult to actually abuse in a useful manner, though, that it was unlikely anyone would have ever been able to develop a working exploit and deploy it in the wild. Thus, if everyone had kept schtum until the fixes were in silicon, and in operating system kernels and hypervisors and software toolchains, no-one would have been the wiser, and no exploits would have been developed.

We're not aware of any malware in the wild leverage the speculative-execution holes, perhaps because they are tricky to abuse and perhaps because so much attention was paid to patching them. There are many, many more flaws out there that are easier to exploit to steal information, for instance.

We'd like to note that El Reg was tipped off to Meltdown and Spectre by noticing obfuscated changes to the open-source Linux kernel in the final months of 2017. These changes indicated some guarantees of security protections provided by today's processors were mysteriously unavailable, suggesting there was a flaw in the CPUs. Combining this information with previous public research and confirmation from industry sources, led us to reporting on the upcoming patches without disclosing exploitation details.

OpenOffice and LibreOffice share a common ancestry

LibreOffice patches malicious code-execution bug, Apache OpenOffice... wait for it, wait for it... doesn't


"Although hardware micro-architects are now aware that security needs to be a first-class design parameter, now black hatters have another vulnerability dimension to pursue; who knows what they will come up with?" Uht continued. "The world has been shaken up by the disclosure; was that necessary and helpful?"

Uht thus suggests that the short-term risks of disclosing bugs publicly outweighs the long-term benefits of quietly hardening products.

Regular and long-time Reg readers will be aware of huge debate over responsible versus full versus no disclosure over the years, so there's not much point repeating it. Well, other than to say: people need to be warned that patches are available, and why they need to be installed, and that some companies won't patch or admit anything unless there's public pressure, in our view.

"Thank you for your comments. No satire," the prof added, when readers of his column criticized his position. "I am serious. Assume someone else does know about a vulnerability. Broadcasting it before a fix has been devised and distributed so that many, many more know about it and can use it with ill intent does not solve the problem, it exacerbates it."

Professor Uht was not available for comment today. ®

Biting the hand that feeds IT © 1998–2019