Is it okay to discuss poor security practices?

Question

I have experienced people actively hindering or flaming people who want to make public or discuss techniques that can break good security habits or schemes of languages, software or operating systems.

In case of open source software and especially open source operating systems, like let's say Linux, do you believe this is the right way? Or should freedom of speech and freedom of science beat the other interests.

Example: someone asks on Stack Overflow how to make a log-in free Linux box and would be down-voted. Someone could say "i know how to do this but I won't tell you, because it is bad for Linux." (I am actually asking this here for fluxbox: https://stackoverflow.com/questions/747066/linux-auto-login)

Please make this a nice discussion, I am looking for the most enlightened answer that includes all the different aspects.

Answer 1

When you hand someone a loaded gun, it's a good idea to first try to ensure they know enough not to shoot themselves in the foot and aren't planning to go on a killing spree.

• If someone asks for help doing something that would be potentially harmful to themselves, then answer if you like - but make them aware of the risks involved. Example: How can I configure a Linux system to automatically log users in as root? (answer provides asker with means of leaving their system wide open to attack)

• If someone asks for help doing something that would be potentially harmful to others, then avoid helping them unless they provide a good reason for it. Example: How can I write a kernel module that hides files and processes? (answer provides asker with means of opening up other users' systems for attack - even if asker has good intentions, it's still malware from the end-user's point of view)

Remember though, that every answer you provide can and probably will be read and used by many people besides the person who asks the question. You can't prevent a malicious user from obtaining the information they need to do something malicious, but you don't have to make it any easier; whenever possible, try to suggest an alternate course of action that won't open up security holes.

---

See also:

• Would you teach black hat techniques in public forums?
• Questions with nefarious intent?

Answer 2

I believe in "responsible disclosure". By revealing an exploit to the world, you potentially compromise millions of systems. I think the best idea is to contact the developers first and give them a chance to patch the bug. If they do not, then you are free to open it up to the world. I believe in free speech, but I also believe it is possible to abuse it.

Answer 3

There are 2 main aspects to this discussion, as far as I can see:

1. Bad security model - security getting in the way
2. Bad user model - not understanding what allowing access to a machine entails.

In the example of the linked question, you present a perfect case for 1 - the system security is causing you a significant delay when starting your machine, which would be a non-issue if you didn't have to interfere halfway through to satisfy some academic security requirement which isn't actually an issue for >50% of home users.

But also there's the problem of people allowing too much access to their machines - like sharing their whole disk with the world and allowing anyone to read and write anywhere, just so that they can copy files to it from work.

At the end of the day, I guess most, if not all of this, is really down to a bad security model - even if technically it's right, if the only thing a user can do to actually use a system is turn off security, then, at the very least, the user interface is wrong.

However, given that the vast majority of security models are wrong in some way and do cause issues, what do you do about it?

A lot of the time, the question's asked on forums are second degree questions, as opposed to first degree questions - for example, someone will ask how to enable worldwide sharing to their disk. If you directly answer that question for them, their machine will probably be totally compromised within a few minutes. If, however, you get them to ask the first order question "How do I share files between home and work", you might be able to give them a much safer answer.

Usually, this is the case - that people start to solve a problem using the tools they have, then hit a wall where the system doesn't behave as they want, and easiest way forward intellectually at that point is to break down that wall rather than back up a bit - hence the bad questions.

Equally, it doesn't help if someone says at the outset "How do I share files between work and home", and the answer comes back "don't be stupid, that's a security risk". Pointing out security implications is part of the answer, but the requirement still stands, if the question isn't answered properly, then how is anyone to know the security difference between sharing a single folder, non-suid, non-exec, fully audited, IP filtered and certificate controlled, vs just opening up the whole machine?

From what I've seen, SO is generally quite good at getting to the first-order questions. That's really the key of the whole thing, that and respecting the validity and requirement of these questions.

Answer 4

Hindering or flaming of anyone who asks wants to discuss a question or answer "that can break good security habits... of languages, software or operating systems" is unacceptable in my book. There is nothing actually wrong with discussing these things.

Breaking security schemes is a gray area if the system is designed to stop you from breaking them (as opposed to it's just not a good idea). This is the difference between asking how to bypass a login password vs simply not having a password. One is breaking the scheme, the other is simply ignoring it.

Hindering a discussion that reveals a zero-day exploit (without a fair chance for the authors to fix it), reveals proprietary or stolen information, or advocates the use of exploits or other security vulnerabilities is probably ok with some exceptions. There's a lot of "un-good" that can come that discussion.

As Jim T points out, sometimes these types of questions may need further discussion of the problem that's being solved. I think it's the responsibility of the community to get more information about the initial problem to make sure that a "bad habit" is the right answer, not necessarily a good answer.

However, there is no reason to withhold information on bad practices. Personally, I would provide the information and heavily caveat the information with warnings that it's a bad practice, some info or links on the "good habits", and maybe alternative ways to solve the problem.

If anything, discussing the bad practices is educational. Not all users are "experts" in security, and some "experts" are in name only. By openly discussing the "bad habits", it may increase the general awareness of security. Some bad habits are a myth. Some good habits are a myth. Only by talking about both can we all get a better picture of the smarter way to practice security.

Answer 5

Talking about security risks and exploits is two sided indeed. You may help someone to make their site more secure but you may also help others to cause havoc. Probably the really delicate things should not be discussed on platforms like SO but rather in smaller circles of people who know each other. These circles would then probably consist of either security specialists or hackers or let's say either constructive hackers or destructive hackers... ;)

I've recently looked at the profile of an SO user who's questions and answers could suggest that the person works in the destructive field... I didn't like it but most certainly a certain percentage of SO users are active in that field and get their answers here as anyone else.

Answer 6

I think it's important to discuss poor security practices. However, if you're going to expose someone's security loophole, it's important that you coordinate with them to fix it first, THEN, after you know it's patched and not still a problem (which on COTS software pretty much means never) then you can discuss it in public.

But I think that the company has a responsibility to close those loopholes in a timely fashion, and only public discourse tends to work to coerce large companies to respond in a timely manner (meaning you catch the eye of higher-ups)

Answer 7

I think some people stretch "responsible disclosure" well past any reasonable limits.

Personally, I think that when you've found an issue you should do the following:
1. Alert the software creator/website owner in question. Ask for a reasonable timeframe to see the problem fixed.
2. a. If they respond, wait until appointed time.
2. b. If no response, try a few more times right up to and including a few phone calls to find a receptive ear at the company.

In the event the problem is not fixed by the communicated date, ask the software creator/website owner for an update. Proceed as you see fit.

In the event the problem is not fixed and you are ignored, publish.

The reason I take this tact is that there are some competing interests. First, software developers aren't omniscient so giving them a head's up is a very good thing. However, the community is at risk while the problem exists. And I guarantee that if you found the bug, others have as well. Most of which won't bother to tell the original developer because they will exploit it.

Hiding security problems by not talking about this is a huge mistake and leads to malware that exploits not one, but several previously undisclosed vulnerabilities at a time.

I fully believe in publishing when the developer refuses to fix or acknowledge the problem because the community of people that depend on that service has placed faith in the developer. They need to know what risks they are taking in order to potentially reevaluate their use of that software.

Further, the community needs to know the details in order to really decide how to proceed. If it's bad enough they'll move to a different provider. Regardless, shame appears to be a powerful motivator and if you found out that all of your clients were shown how insecure your software is I can guarantee you will move heaven and earth to fix it now.. Or go out of business. Which, with this type of problem is the only two acceptable solutions.