Security implications of loading custom reports

[John Ralls]

On Oct 23, 2014, at 9:25 AM, Derek Atkins <warlord at MIT.EDU> wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>>> I'm not sure this is possible in guile only. A report is written as
>>> a guile module. Loading the module already executes code
>>> (gnc:define-report). That code can be abused do bad things when
>>> loading a custom report.
>> 
>> Wow. That’s an incredible failure for something that’s promoted as an
>> application scripting language.
> 
> I'm not sure that people care about security when you're modifying your
> own application.  Similarly, emacs' e-lisp lets you get into pretty much
> any part of the application.  That's not considered a failure, either.
> It's a feature.
> 
> We could limit the "damage" by limiting which APIs are available.  But
> it's a turing-complete language so you could do anything.
> 
> I just don't see the reason to rework all this.  What's the threat
> you're trying to prevent (other than "broken report crashes the app --
> which we should fix by catching the exception).
> 

The threat is someone malicious installing a script either by phishing the user or by gaining access to the user’s machine. Such a malicious script wouldn’t be limited to crashing GnuCash: It can do anything any program can do.

Yes, I agree that emacs has even more vulnerability, but we’re not responsible for emacs. In some ways it’s a feature for emacs, but it’s also the reason behind the snarky “emacs isn’t an editor, it’s a way of life”. Unlike emacs, GnuCash doesn’t aspire to be an all-in-one desktop and development environment.

Regards,
John Ralls