| 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