 |
 |
> 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