Re: Fixing security vulnerabilities before new releases

Mike Kupfer <[email protected]> writes:

> Eshel Yaron wrote:
>
>> For Emacs 31, the mitigation can be as simple as:
>> 
>> diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
>> index 132b9211f88..48b9e3a3638 100644
>> --- a/lisp/vc/vc-hooks.el
>> +++ b/lisp/vc/vc-hooks.el
>> @@ -299,7 +299,8 @@ vc-find-backend-function
>>    "Return BACKEND-specific implementation of FUN.
>>  If there is no such implementation, return the default implementation;
>>  if that doesn't exist either, return nil."
>> -  (let ((f (vc-make-backend-sym backend fun)))
>> +  (let* ((read-symbol-shorthands nil)   ; Mitigate CVE-2026-XXXXX
>> +         (f (vc-make-backend-sym backend fun)))
>>      (if (fboundp f) f
>>        ;; Load vc-BACKEND.el if needed.
>>        (require (intern (concat "vc-" (downcase (symbol-name backend)))))
>> 
>
> Couldn't an adversary simply change the malware to use a different
> function, one that is invoked when visiting a file and doesn't go
> through this code path?

Not easily: triggering the vulnerability requires a few stars to align,
not just any function is attacker-controlled.  I went over the attack
surface reachable when visiting a file, and this covers the main one.
There is one more place that needs a similar treatment, but I didn't
include it here so as to avoid disclosing another attack vector before
we mitigate it.

You can also always test it yourself.  If you do find a way around
this mitigation, please do tell, off-list, of course.

Sean/Eli, should I go ahead and install this mitigation?


Best,

Eshel