Slashdot Mirror
Including Source for a Potential Hacking Tool?
rajinder asks: "What are the experiences of Slashdot folk when it comes to including the source code of a security tool in their final year dissertation? I have a project in mind that I want to submit that can be used by admins to evaluate the security of their wireless network(s), but it could just as easily be used for their nefarious purposes. Before I submit the idea, I wanted to see if anyone knew of potential hurdles I would have to face. Anybody ever done something similar? The official rules about what is allowed is available in this PDF [or the HTML version], but I don't see anything relevant to my dilemma (the relevant section is 2.4, page 9) UK university-system specific info would be appreciated, but I plan on carrying on my education in the US, so info from either side of the pond would be good. Does anyone know if I would be able to GPL the code afterwards and put it out there? Would it remain property of the University or the student that wrote it?"
For that you have to contact your undergrad advisor.
For me it was possible to GPL the code.
Some profs however like to keep it.
Some universities have different rules as to this sort of thing.
Sometimes you can get away with a simple NDA in the Document.
I would ask you specific registrar/school office about the detailed rules that you have to abide by.
Are your concerns about ethics or liability?
Is there a differance between authoring (and submitting) vs. publishing (as in what the Uni. dept. will do)?
Unless specified by your university the final year dissertation is your own, or at most it can be your and your advisor's, or similar things. You're required to give a (certain number of) copy(es) to your university library, and they will let the public see it, but that's not public domain.
Of course different universities have different policies, so you may end up with stricter conditions, here the rule is to ask local competent people (if reading the official rules doesn't help).
You HAVE to submit all your project source code with your dissertation. I even had to print mine out. Those are the rules.
Once you submit the dissertation, it is the University's property, their copyright. They get your code, you get a degree. Trust me, you'll write a lot of code in your lifetime, you're getting the far better end of the bargain. Some poxy code for a ticket to the good life. Jobs that need degrees just to apply pay a LOT more than jobs that let anyone in.
If you really want to GPL your work, talk with your project supervisor BEFORE you do anything rash. Check that the university doesn't want to take the code further and develop it, or market it, or such. Then they might GPL it themselves (as they now own it), or they might allow you to create a GPL work-alike of the code you just gave to them without setting the attack lawyers on you.
Does my bum look big in this?
You are not responsible for what other people chose to do.
(The number of people leading screwed-up lives or screwing up other peoples' lives, because they don't understand that principle, is vast.)
That said, there's no reason to leave your tool in ready-made form for nefarious attack that any script kiddie to download and run.
Since you're producing a professional work, publishing the code in the text of your thesis pretty much guarantees the only people that will get a hold of it will be intelligent and perserving people with an interest in what you've contributed.
While it's not absolutely foolproof, the set of people who are both intelligent and persevering have better than average ethics, IMHO.
Exactly the same principles apply to other non-IT information (chemistry, biology, nuclear physics) which can potentially be used for evil purposes.
The solution is not to try and stuff the genie back into the bottle, but to try to find ways of generating fewer new nefarious people.
"Provided by the management for your protection."
A few things:
1) Unless you sign an IP agreement (usually for an industry funded research project) you can GPL it.
2) The dirty little secret the mainstream security industry doesn't want you to know is that all the useful & good tools security tools are open source. In general, you risk losing credibility among your peers if your software is NOT open source.
3) If your project has to do with wireless (in)security it's likely not going to be very novel. Just about all the wireless encryption standards (GSM A/51, W/TLS, WEP) are all broken with implementations to verify this.
4) Security researchers long ago realised that full disclosure is the only way to fix security vulnerabilities. Besides as another poster pointed out kiddiez will not understand your paper, only serious security researchers. And in general, they probably already know whatever it is your paper is going to be about.