[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from
From: |
Steven Allen |
Subject: |
Re: [POLL] We plan to remove #+LINK: ...%(my-function) placeholder from link abbreviation spec |
Date: |
Fri, 28 Jun 2024 10:01:22 -0700 |
Suhail Singh <suhailsingh247@gmail.com> writes:
> Steven Allen <steven@stebalien.com> writes:
>
>> 1. While this feature no longer invokes completely arbitrary code, it
>> still allows an attacker to call any function marked as "pure" which
>> is a pretty large attack surface.
>
> I am struggling to assess this, because it's not clear to me what the
> threat model is. Could you please elaborate? How are the attacker and
> potential victim interacting; what is the attack vector(s); who are the
> threat agents and what is their goal that we are trying to guard
> against, etc?
Scenario: Attacker sends an email containing an inline org-mode part with a
malicious link abbreviation.
The concern is that, e.g., there may b a function _marked_ as pure
that's not actually pure, leaks some information, and/or has a security
vulnerability (e.g., a C function exposed to lisp that's marked as pure
but internally has, e.g., a buffer overflow).
Of course, the actual attack hypothetical. The question being asked here
is: is the %(..) specifier in link abbreviations useful enough to warent
the potential risks.
>> You can, of course, write that function; but then you might as well
>> use org-link-abbrev-alist instead of defining a local #+LINK.
>
> Perhaps I misunderstood, I thought the thing being polled was whether or
> not to allow org-link-abbrev-alist to have REPLACE (per its docstring)
> be a function. I.e., if %(my-function) is removed, so too would the
> ability to have a function in the REPLACE position in
> org-link-abbrev-alist. Did I misunderstand?
The question is whether or not %(function) placeholders should be
allowed in #+LINK: lines. It doesn't actually say anything about
allowing them in the global org-link-abbrev-alist. But to be explicit,
there are three options:
1. Allow them in both #+LINK: lines and the global
org-link-abbrev-alist.
2. Allow them in org-link-abbrev-alist only.
3. Remove them entirely.
- Re: [ANN] Emergency bugfix release: Org mode 9.7.5, (continued)
[POLL] Bug of Feature? Attack vector via deceiving link abbrevs (was: [ANN] Emergency bugfix release: Org mode 9.7.5), Ihor Radchenko, 2024/06/28