> On Fri, Dec 16, 2011 at 21:42, Eric Hellman <[log in to unmask]> wrote:
> >
> > You'll be happy to know that as bad as things are, they've improved
> considerably! I showed several ILS vendors how I could insert arbitrary
> javascripts into their products. Some of them fixed their products in the
> next update cycle, some took a couple of years. One particularly nasty
> vulnerability I am unable to talk about, it was so nasty and close to home.
> But the general problem persists. Perhaps an outing process would be useful.
> >
>
> Leaks4Lib?  +1
>

I understand the sentiment, but I'm not sure it's the best approach in a
library environment.

Although certain types of issues can be corrected relatively easily, some
serious holes are far harder to plug without damaging operations as they're
deep in the system or critical functionality depends on them. This is
particularly true with legacy systems.

Getting a peon job working with systems/data and social engineering are by
far the most effective ways to crack any security. Plus, libraries are such
lousy targets that anyone willing put time into a decent technical hack
would be better served directing their energies where the ROI would be
better.

Security through obscurity is not a good practice, but it still makes a big
difference. If you work with certain systems long enough, the obscurity
part will disappear for you, but it won't for the type of people who'd
engage in nefarious activity. Given the small size of the library market
and development resources to fix vulnerabilities, it's better not to leak
IMO. Or maybe tell individuals who could fix things offline. Much of the
time, things still won't get fixed, but you still come out ahead. You don't
want to trigger a situation where the cure is worse than the disease.

It's easy to imagine problems that could result from any particular
vulnerability, but reality is much kinder. Just remember, anyone who can
pick up a rock has a key to your home and car. Yet we all sleep well at
night.

kyle