Documentation and Jira cleanup are all complete, for Hadoop-1.1.0 and 1.0.4.
On Sun, Oct 14, 2012 at 9:08 PM, Matt Foley <[EMAIL PROTECTED]> wrote:
> The release of Hadoop-1.1.0 has been voted, accepted, and posted.
> It is available in SVN and Maven, as well as at
> It is still propagating to mirrors, and should be available on all mirrors
> by this time Monday.
> The documentation update is being worked on now and will be available by
> Monday morning.
> This release includes approximately 135 enhancements and bug fixes
> compared to Hadoop-1.0.4,
> - many performance improvements in HDFS, backported from trunk
> - improvements in Security to use SPNEGO instead of Kerberized SSL for
> HTTP transactions
> - lower default minimum heartbeat for task trackers from 3 sec to
> 300msec to increase job throughput on small clusters
> - port Gridmix v3
> - set MALLOC_ARENA_MAX in hadoop-config.sh to resolve problems with
> glibc in RHEL-6
> - splittable bzip2 files
> Like the recent Hadoop-1.0.4 maintenance release, this release also
> includes the Security bug fix for
> CVE-2012-4449, discovered by Daryn Sharp and fixed by Owen O'Malley. The
> CVE announcement is
> below. All users are encouraged to upgrade to either 1.0.4 or 1.1.0 as
> soon as possible to address this
> security problem.
> Best regards,
> --Matt Foley
> Release Manager
> *CVE-2012-4449: Apache Hadoop security token vulnerabilities
> Severity: Critical
> Vendor: The Apache Software Foundation
> Versions Affected:
> 0.20.X: All versions
> 0.23: All versions before 0.23.4
> 1.0: All versions before 1.0.4
> 2.0: All versions before 2.0.2
> Users affected:
> Users who have enabled Hadoop's Kerberos security features.
> Malicious users may crack the secret keys used to sign security
> tokens, thus granting them the ability to fabricate tokens for
> privilege escalation. Malicious users may also launch unauthorized
> tasks as an arbitrary user for privilege escalation.
> When Hadoop's security features are enabled, clients initially present
> Kerberos credentials to authenticate to a service such as the
> NameNode. A client may then request a security token for subsequent
> authentication within the Hadoop cluster. The client receives a
> security token and a corresponding signature for the token, generated
> using the HMAC algorithm and a SHA1 hash.
> Token passwords are generated using a trivial secret key length (20
> bits). A key of this size can be brute forced in at most a few
> seconds. Once the secret is cracked, one can generate arbitrary
> tokens to impersonate other users. These fraudulent tokens may be
> used to gain unauthorized access to data or disrupt services within
> the cluster. With default secret key rolling values, a cracked secret
> may often be exploited for a couple days before another secret has to
> be cracked.
> Some token-based services, such as the NameNode's delegation tokens
> for the namespace, are immune from a compromised secret key because
> they record the generated tokens. A fraudulent token with a valid
> password will rejected since the service will know it did not generate
> the token. Services that generate a token on behalf of another
> service and rely on a shared secret for the other service to validate
> the token's password are especially vulnerable.
> HDFS (all versions):
> Malicious clients cannot gain unauthorized access to the namespace.
> Malicious clients may however gain full access (read, write, and
> delete) to any block based on knowledge of the block id.
> MapReduce (1.x):
> Malicious clients may intercept task data, task logs, alter task
> status, and disrupt tasks from executing or completing. A malicious
> client may also inject data into a Pipes-based job.
> Yarn (2.x only):
> Malicious clients may perform the same attacks as MapReduce. An