On Thu, 25 Nov 2010 00:35:59 +0000, Rob Kendrick wibbled on for an age:
On Wed, Nov 24, 2010 at 09:03:24PM +0000, Chris Young wrote:
> There is a security flaw in this library due to the implementation
> and its translation to a system global context. All users of this
> library get the same context and thus, the same linked-list set of
> strings. This has the advantage of greater efficiency, and is
> necessary so both (eg) css.library and NetSurf can share strings. Any
> sensitive data stored in lwc_strings can easily be extracted by a
> malicious user of the library. The nature of wapcaplet.library does
> not lend itself to storage of personal information, so it is not
> expected that any application will intentionally do this. As
> wapcaplet.library could easily be patched to intercept strings as they
> are being set, and - in a system without memory protection - any
> application can read strings from memory regardless, this additional
> problem is deemed insignificant. The warning "do not use
> wapcaplet.library for sensitive data" should be heeded (instead link
> libwapcaplet.a, or better yet use something more appropriate). This
> will be revisited if it is deemed a significant risk.
I may be missing something, but how is this an issue at all? Do all
AmigaOS processes share the same context pointer or similar?
On other OSes, each process gets its own "copy" of the
other processes can't reach the data a process has stored. If this
isn't true, the security issue is with the OS, not libwapcaplet.
Actually it's just down to the differences between C-style libraries
and .libraries. A .library exists once in memory (code+data), so any
callers will share the same global variables. (the security flaw
isn't with libwapcaplet per se, only this .library version)
Consider a simple example:
int a = 0;
void setvalue(int b)
a = b;
This is linked into program A and program B as a C-style libexample.a.
If program A calls setvalue(5) this will not affect program B, which
has its own copy of libexample and global variable "a".
However, if this was an example.library, when program A calls
setvalue(5), program B - assuming a corresponding getvalue() function
- would get this value back.
.libraries tend to have an Alloc() function which returns a pointer
which can then be passed to any functions that needs it, rather than
having this as a globally accessible function. In the context of
wapcaplet.library, lwc_initialise would need to return a pointer to
the context, which would then need to be passed to any lwc function
which needs a context pointer - which is only lwc_intern_string(), as
the lwc_string structure could easily be expanded to hold the context
pointer which that string has been created in.
This would obviously need to be cascade down to any calling functions,
and lwc_finalise will need to free the context once finished.
If it's only being used for public things like CSS property names then
leaving it with one global context isn't an issue, and should actually
be beneficial as the data will be shared with multiple programs (which
was of course what set the alarms bells off in the first place)
The other solution is to change back to using .so, but I was trying to
move away from them as they cause problems, have a slight overhead and
don't work properly on OS4.0.