lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <000001c23b18$38632230$3dd6020a@fujilap> From: steve at entrenchtech.com (Steve) Subject: "Free Hacker Manifest" Here is the original poster. Possibly the author. Date: Sat, 03 Aug 2002 09:05:10 -0400 From: qwerty qwerty <qwertyqwerty_15@...os.com> To: bugtraq@...urityfocus.com Subject: Free Hackers Manifest > -----Original Message----- > From: full-disclosure-admin@...ts.netsys.com > [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Len Rose > Sent: Saturday, August 03, 2002 6:19 AM > To: full-disclosure@...ts.netsys.com > Subject: [Full-Disclosure] "Free Hacker Manifest" > > > I just received this in my mail, I have no clue as to the > identity of the person who sent it to me. > > ################################ begin inclusion > ########################################### > > |=-----------------------------=[ Judgment Day > |]=-----------------------------=| > |=------------------------------------------------------------ > ----------------=| > |=-------------------------=[ Free Hackers Manifest > ]=------------------------=| > > > Free Hackers versus "Ethical-Corporate-Hackers" > > > In respect with the spirit of the manifest Authors > will remain forever > anonymous. The manifest is offered to the community > under the Free > Documentation License (FDL) [http://www.gnu.org/copyleft/fdl.html]. > > > --[ Contents > > 0 - Facts > > 1 - Accused, to whom the crime profits > > 1.1 - Software Vendors > 1.2 - Security Service Firms > 1.3 - Fallacious "hackers" > > > 2 - Defendants, the rights at stake > > 2.1 - User Land, hear my cry > 2.2 - Hacker Space, free as in freedom > > > 3 - Indictment > > > 4 - Verdict > > > 5 - Reference > > > > --[0 - Facts > > Some will share, others will keep gems to themselves. > > We are judge to none. > > Today some wish to force the ones that shares, not to, for > it depreciate the value of greed. > > We will defend freedom, and fight to preserve the > open-space, that air we breath. > > -What happened ?- > > Once upon a time many of those "Chief Technologists/Hacking > Officers" of the flourishing security industry were just a > bunch of young pranksters eager for technology. > > And the pranksters collected into groups lurking on some > computing specifics: hacking. Many good things arose from > those groups, sweets for the brain. > > And the groups got respect, for their findings came atop a > pyramid of knowledge that every one helped build. > Recognition by peers, ultimately being called a "hacker", > was the highest retribution. > > And the kids went to high school to get an MBA, get a car, > get a job, get money, try to make an aggressive buy-up on > that pyramid, trade it for a buck. In the same course > raise of communication and Internet growth had Corporations > began to fear those strange pizza-cola eaters: The > corporate knowledge, they called "trade secrets", they did > not want to trade with hackers - at all. > > Secret service has a saying: "kiss the hand you > couldn't cut", and so corporations cunningly inflated > pizzas with money, and some "old school-full > disclosure-non profit hackers" turned to security firms > belly dancing with software vendors. > > -Then- > > Some started regulating with "disclosure policies" [1] [2], > their publishing of knowledge. Not yet "Non-Disclosure > Agreements" though, but a step forward into the semantics. > And called it "ethic" ... toward whom ? > > -The unthinkable happened- > > In a more radical move a bunch tried to -how funny- hack IETF > and push for a generic disclosure policy [3]. Can you > see that -how strange- Microsoft's employee in the " > Aknowledgement " section of the document ? All bullets > for the underground, all benefits for the corporate. No > commitments to the people. Thankfully IETF reacted > strongly, the draft is no more, for now [4]. > > -A putsch from above- > > Helped in that by what once was the "elite", a - pretending - > general agreement emerged to restrict hacking publications > without "ethical" peer review [5]. They want to moderate > your mind, the newsgroups, the mailing lists, all main > vectors for public information not in accordance with strong > content but with disclosure policies compliance. > Legislation is on its way too. Can you say lobbying ? > Can you see the ten villains ? > > This will not go through. > > > --[1 - Accused, to whom the crime profits > > > --[1.1 - Software Vendors > > Side note: In trying to sell you hype some uses > confusion of terms. Very simple psychology: sell shit and > call it a rose -or- say the rose is made of shit. It's > amazing how many people calls free software programmers > "Software Vendors". Don't get confused, one of them is not > asking for money. > > Here's a trade secret: out of a 100 found software > vulnerabilities almost 100 will initially come from end > users experiencing a bug, and passing the information > around (also count disgruntled ex-employees passing code around). > > There was a time when information couldn't flow, and as an > end user you would have to pay to get a patch. Software > Vendors are really longing this time. > > How does "software insurance" smells to you ? > > -So they want hackers to adopt "disclosure policies"- > > The most candid argument is in warning the vendor will help > to get the patch out before the vulnerability hurts. > Everyday experience proves this to be a nonsense, > because systems are actively exploited LONG before any > kind of announcement [6], because vendors can sit for months > on an unpublished bug [7]. > > The reasons why vendors are pushing for "d.p." is ... well > more down to earth: > > Without vulnerability announcements, products looks more > secure: it helps the sales. > > Working hand in hand with "ethical hackers" increases the > credibility of the > vendor: it helps the sales. > > Forcing vulnerability authors to help vendors [3] allow them > to benefit from a free task force: it helps to cut down the costs. > > Asking for a delay between discovery and disclosure lets > vendors have a happy face in front of the press. Good > press helps the sales. > > At last, knowing who authors the advisories helps > vendors for more spin control. > > > --[1.2 - Security Service Firms > > You can get software for intrusion detection, penetration > tests, firewalling (etc ..) for free [8]. > > You can read from the Internet all necessary documents on > security, and become an expert yourself. > > Security Service Firms sells consultancy services and > security software. Where does the competitive advantage > stands ? Mainly in the level of expertise between you > and them. Would it help those firms sales to restrict public > access to "valuable" piece of information ? > > It helps their sales to have access to early releases of > security issues before you do. > > It helps to cut down their costs to have the free community > research those bugs for them. > > So they want the community to submit all findings to a > central intelligence that would sell early release of > information to security firms, whom in turn sells you > pattern updates for their tools and try to discredit free > projects [9]. Already, they are reports of big gaps between > the sending of some advisory to a well known security > mailing list and the time it finally get published. > > To discourage you from publishing information or to try > access it those firms will work with governments to rule > it illegal. Saying its military grade secrets [10]. > Which also fits political agenda to protect interests of > "big business", and further control any free speech that > could modify the current balance of power. > > To force you into buying consultancy you will see those firms > soon working hand in hand with insurance companies that > require "independent an professional peer review" of you > entire computing infrastructure. As we know audit firms > reports are the most qualified and trustworthy items one could find. > > Then, what if running a software would require it to be > "tested and approved", as well as the hardware [11] ? > > > --[1.3 - Fallacious "hackers" > > Granted social engineering is part of hacking, you would be > surprised how many renown "Ethical Hacker" have so poor > coding skills. > > The truth is they take credit for code anonymous writes, or > better even, they say how bad they manage to exploit a bug > but they won't publish for "ethical" reasons. The truth is > that ruling it illegal to release exploits fits them > perfectly, so they can still have you think they are > "hackers" when they can't make the difference between a > shell code and some ASCII art. > > On a larger scale its the very understanding of what a > "hacker" is that gets compromised. Until recently you > would be called a "hacker" by peer review of your work, > retribution by recognition of an intellectual elite. In the > avail of [3], a "hacker" would not be a skilled individual > but someone respectful of the "ethical" rules, accredited by > security firms. > > > --[2 - Defendants, the rights at stake > > --[2.1 - User Land, hear my cry > > User rights is mostly unheard in the security world. > > Everyone must have a rightful access to information to > protect themselves against vulnerabilities and patch their > systems in time. > > Curiously security firms breaks their own disclosure policies > when the affected software is free software [12] [13]. What > does that two-face attitude means ? Early release in the > event of free software (even before a patch is available), > moderated information when money is engaged. > > Without a warning, users are in a false sense of security. > > When someone finds a bugs the only certainty is that the bug > exists for as long as the software was initially released. > As security firms recognize [14], underground exploits > exists before any users hear publicly about the bug. > Keeping a vulnerability private is just an open door to crackers. > > Ironically crackers can even be tough new tricks by the > "Ethical Hackers", granted they spawn a few thousands bucks > for the exclusives [15]. > > > --[2.2 - Hacker Space, free as in freedom > > Hacking is a kind of science, and as such should be > discussed on its logical basis by anyone that wish to > participate where ever anonymously or not. Discovering a > vulnerability should not imply obligations of any kind for > the discoverer - except publishing it, as an engagement > towards the scientific community. > > Hackers need anonymity for his own personal security - > We've seen to many people in trouble with secret service > and justice for publishing scientific facts, see the > DeCSS case [16] or the Russian e-book hacker [17]. > > Also, some disclosure policies makes it compulsory for the > bug discoverer to > help vendors in reproducing and/or solving the bug. > This is just not > acceptable, discovering a vulnerability should follow > military rule: fire and forget. It's not a hacker's job to > solve the issue, he's not responsible for the existence > of the bug in the first place. > > > --[3 - Indictment > > Free hacking is in danger, not directly by an opposing force, > not in a struggle of power, but by ex-hackers that have turn > their face from scientific curiosity into greed. The very > ones that took part in building the foundations of our > common knowledge, want to steal our dreams and wrap it in a > shiny paper. > > The many ways in which they try to enforce control upon > free hackers may be found throughout the reading of their > "disclosure policies", that includes: > > - The infamous "30 days delay" between informing a software > vendor of a bug and the public at large - > > This is ridiculous and should be a mere "30 days delay" > after the initial release of the software before anything > gets published simultaneously to all possible audience, > because any bug could have been discovered and exploited at > any time since then. > > - Removal of exploit codes - > > Users need to check if their systems are vulnerable: > software and version numbers as included in announcement > are not enough, a check is mandatory since software > programmers often re-use the same code between various > software [18]. Hence, between bug announcement and proof of > concept code release one could choose for -no more than- > a week delay. > > - Multi-level moderation - > > Usual media used for hacking discussion should never be > moderated nor censored for anything else than accuracy. > Would the information flow come to a stop, be prepared to > wide open your wallet, because those would be the time > of the mediocre tyranny. > > Would some try to enforce their "disclosure" rules upon > all, a new hacker network has to arise, totally free. For > this purpose we prepare, and invite free hackers to join > in the manifest below. > > > --[4 - Verdict > > > > --- Free Hackers Manifest --- > > (1) Licensing > > This Manifest is published under the Free > Documentation License (FDL) > (http://www.gnu.org/copyleft/fdl.html), any publication > made explicitly in > respect with the terms hereby will also follow the FDL. > > (2) Freedom > > The author of a published document has the right to > remain anonymous, and > protect himself from further prosecution or pressure > of any kind. His > communication should be regarded as a scientific work and > treated as such. > > (3) Respect of others > > The minimum amount of time before a software bug is published > can not exceed 30 days after the initial software release, > in respect of users protection whom systems are already > exposed. Past the 30 days delay of the initial software > release a security bug must be published as soon as possible. > > A delay between the bug announcement and the proof of > concept code (if available at the time) must not > exceed 1 week for users to test the vulnerability of > their systems. > > Although announcement will be made by all means possible, > Free Hackers freedom must be ensured at all times and as > such some mediums of information might just be not suitable > (as taking contact with vendors directly). > > The Free Hackers recognize their scientific work was made > possible thanks to the contribution of many others and will > pursue the construction of that common knowledge for free. > The Free Hackers will not participate in actions that goes > against the spirit of this Manifest (such as holding > restricted details of public announcements for private firms). > > (4) Dormant network > > A dormant network of Free Hackers is to be built, for this > purpose everyone that agrees with the spirit of the > manifest is encouraged to add his e-mail ROT-13 encoded > (to foil spammers) below with the ones already there, and to > show the document on his/her web site > as u.r.l. > "<web-site>/Free-Hackers-Manifest.html". > > Anonymous Free Hackers that wish to support the Manifest are > encouraged to do so by having their e-mails added by a fellow > Free Hacker on his/her web site. > > Whenever it will be made clear that traditional means of > public information are compromised to the point the above > rules are systematically broken (like enforcing any kind > of disclosure policies, delaying transmission of information > or retaining technical details), the below list of e-mails > will be used to activate a Free Hacker Network as such: > > (a) Using a web search engine, one will look for every instance of > "Free-Hackers-Manifest.html" were he could easily extract a list > of Free Hackers e-mail. The web search engine could help in > determining the most pertinent lists as being the most linked to, > for instance. > > (b) The group will work on releasing a client tool for a peer-to-peer > network such as the freenet project (http://www.freenet.org), the > release name for the tool will be > "Free-Hackers-Manifest-<YYYY/MM/DD>.tgz". The tool will be made > available by a link on the Manifest web page. > > That network will allow for anonymous posting from web based mail > client and user base moderation on source e-mails (per original > posts and threads). > > It must not be possible for any individual to alter the content > of any message nor block its diffusion to others. > > Spammers will be blocked on the client side, much like one does > it with anti-spam code on his mail client, as well restrictions > could be set on the number of message one individual is allowed > to post per day. > > (c) If a group name is required on that network it will be of > "Free-Hackers-Manifest". > > (5) ROT-13 e-mail list > > sbb@one; > > ----------------------------- > > > > --[5 - Reference > > > [1] Full Disclosure Policy (RFPolicy) v2.0 > http://www.wiretrip.net/rfp/policy.html > > > [2] Extract from "RFPolicy for vulnerability disclosure", > http://archives.neohapsis.com/archives/vuln-dev/2000-q2/0908.html > > > My intent is not to push this policy onto the > community. Everyone can > > obviously do whatever they feel like. But *I* > will be using this > > disclosure policy in all future security disclosures, > and I encourage > > anyone wishing to use or modify it, to do so. > > > [3] Responsible Vulnerability Disclosure Process, > > http://www.ietf.org/internet-drafts/draft-christey-wysopal-vul > n-disclosure-00.txt > > > [4] Bug-reporting standard proposal pulled from IETF > > http://www.computerworld.com/securitytopics/security/story/0,1 > 0801,69391,00.html > > > [5] Re: Remote Compromise Vulnerability in Apache HTTP Server > David Litchfield <david@...software.com> > > http://online.securityfocus.com/archive/1/277259/2002-06-14/20 > 02-06-20/0 > > > [6] Remember when RootShell claimed to be victim from a hack > via ssh back in > 1998, how long before the first advisories on > SSH weaknesses ? > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th > =9a1078fad663e9e&rnum=1 > > > [7] Compare CVE assignement dates of > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0071 > and > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0079 > with > > http://www.microsoft.com/technet/treeview/default.asp?url=/tec > hnet/security/bulletin/ms02-018.asp > Also notice the synchronicity of assignements dates for > different research > groups, all released under Microsoft the same day. > > > [8] http://www.nessus.org, http://www.nmap.org, > http://www.openwall.com, > http://www.snort.org, http://netfilter.samba.org, ... > > > [9] No pointer - but http://www.nessus.org was not > accessible to "unfair > companies", which used nessus to generate a lot of cash, > without helping the > community in any way. > > > [10] Uniform Computer Information Transactions Act (UCITA) > http://www.arl.org/info/frn/copy/ucitapg.html > > > [11] Digital rights management operating system > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HIT > OFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='6,330, > 670'.WKU.&OS=PN/6,330,670&RS=PN/6,330,670 > > > A fundamental building block for client-side content > security is a secure > > operating system. If a computer can be booted only > into an operating > > system that itself honors content rights, and > allows only compliant > > applications to access rights-restricted data, then > data integrity within > > the machine can be assured. This stepping-stone to a > secure operating > > system is sometimes called "Secure Boot." If > secure boot cannot be > > assured, then whatever rights management system the > secure OS provides, > > the computer can always be booted into an insecure > operating system as a > > step to compromise it. > > > [12] ISS Advisory clarification > Klaus, Chris (ISSAtlanta) <CKlaus@....net> > > http://online.securityfocus.com/archive/1/278189/2002-06-15/20 > 02-06-21/0 > > > [13] ON THE CUTTING EDGE 2001: A Security Odyssey > > http://www.infosecuritymag.com/articles/december01/departments > _news.shtml > > > Under the proposal, coalition members would have a > 30-day grace period to > > disclose vulnerabilities with law enforcement > agencies, government > > agencies and their trusted client. In theory, this > will give software > > vendors a head start in correcting the problem before > anyone knows it > > exists. > > > > So far, Microsoft has drafted the support of BindView > (www.bindview.com), > > Foundstone (www.foundstone.com), Guardent > (www.guardent.com), @stake > > (www.atstake.com) and Internet Security Systems (www.iss.net). > > > [14] Apache HTTP Server Exploit in Circulation > > http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp? > oid=20524 > > > ISS X-Force has learned that a functional remote > Apache HTTP Server > > exploit has been released. This exploit may have > been in use in the > > underground for some time. > > > [15] http://www.blackhat.com/html/bh-usa-01/bh-usa-01-speakers.html > > https://www.worldwideregistration.com/registration/vegas-black hat-usa.html [16] DVD hacker Johansen indicted in Norway http://wneclaw.wnec.edu/faculty/kalodner/courses/softwarelaw/JohansenArr est.html [17] Russian Author of Adobe eBook Password-Removing Software Held Without Bail, Faces Possible 5-Year Prison Term http://www.ebookweb.org/news/tech.20010716.elcomsoft.roush.htm [18] see numerous vulnerabilities announced after initial snmp bug, apache, or bind. This document is pgp-signed below. Don't trust any claim of authorship unless that individual may produce the necessary PGP keys. iD8DBQE9LX2siFdkMnNRCv0RAnAKAKCmAo2B/dnUdpahsaPudQsLIiQJKACfQeXV joLXFpUVRZZQGHCl0VrTyEE= =OPrO __________________________________________________________ Win a First Class Trip to Hawaii to Vacation Elvis Style! http://r.lycos.com/r/sagel_mail/http://www.elvis.lycos.com/sweepstakes ################################ end inclusion ########################################### _______________________________________________ Full-Disclosure - We believe in it. Full-Disclosure@...ts.netsys.com http://lists.netsys.com/mailman/listinfo/full-disclosure
Powered by blists - more mailing lists