Send CentOS-announce mailing list submissions to
centos-announce(a)centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-request(a)centos.org
You can reach the person managing the list at
centos-announce-owner(a)centos.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."
Today's Topics:
1. CESA-2014:0127 Moderate CentOS 6 librsvg2 Update (Johnny Hughes)
2. CESA-2014:0126 Moderate CentOS 6 openldap Update (Johnny Hughes)
3. CEBA-2014:0125 CentOS 6 tigervnc Update (Johnny Hughes)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Feb 2014 05:35:04 +0000
From: Johnny Hughes <johnny(a)centos.org>
Subject: [CentOS-announce] CESA-2014:0127 Moderate CentOS 6 librsvg2
Update
To: centos-announce(a)centos.org
Message-ID: <20140204053504.GA49218(a)n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2014:0127 Moderate
Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0127.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
7f582307cabadd730387b49d93e454ab8e9007a98c991210ed3b86f67b9f29f9 librsvg2-2.26.0-6.el6_5.2.i686.rpm
4632e3a6c32f7e6979ea467548f33f24fa1bfb3ade3de46fb8377864346098bf librsvg2-devel-2.26.0-6.el6_5.2.i686.rpm
x86_64:
7f582307cabadd730387b49d93e454ab8e9007a98c991210ed3b86f67b9f29f9 librsvg2-2.26.0-6.el6_5.2.i686.rpm
664950eb6b1cb297982ebf569a537b80c8c5605b01ab996dbfe41287a1aa553c librsvg2-2.26.0-6.el6_5.2.x86_64.rpm
4632e3a6c32f7e6979ea467548f33f24fa1bfb3ade3de46fb8377864346098bf librsvg2-devel-2.26.0-6.el6_5.2.i686.rpm
d7e7d9a1a0ff23aa4807542f22960580d0e81571af316dc168acf077097e6171 librsvg2-devel-2.26.0-6.el6_5.2.x86_64.rpm
Source:
59a805614f98312172e2a467079481f9eda8dc05d8438b1be852879e51b2a4d0 librsvg2-2.26.0-6.el6_5.2.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos(a)irc.freenode.net
------------------------------
Message: 2
Date: Tue, 4 Feb 2014 05:35:44 +0000
From: Johnny Hughes <johnny(a)centos.org>
Subject: [CentOS-announce] CESA-2014:0126 Moderate CentOS 6 openldap
Update
To: centos-announce(a)centos.org
Message-ID: <20140204053544.GA49526(a)n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Security Advisory 2014:0126 Moderate
Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0126.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
07c4f6e0049e9e53255b3effe63421d64d48de4eafc116b28c9b77c63a8e24ec openldap-2.4.23-34.el6_5.1.i686.rpm
26dde0c2324e45b0b7aad2eca7c018f5bc78e49465b96ce281ab729d9c0a71ab openldap-clients-2.4.23-34.el6_5.1.i686.rpm
f4e3a08cb06c1c7442b176cabcd3f2dc3f9a2d7eaebae1cf0a927a2065ebad17 openldap-devel-2.4.23-34.el6_5.1.i686.rpm
fe828f57493fb60f8fe5f9dcda25e2ed1980fdf1df42f3cefdcca68f2ff34a63 openldap-servers-2.4.23-34.el6_5.1.i686.rpm
500ae2b4280dd4f638524cfe24cc374232c5e4faca262a37dc3d3446e69a7b9a openldap-servers-sql-2.4.23-34.el6_5.1.i686.rpm
x86_64:
07c4f6e0049e9e53255b3effe63421d64d48de4eafc116b28c9b77c63a8e24ec openldap-2.4.23-34.el6_5.1.i686.rpm
27cae8bc3e94267b8b319c6cb1d49ba556130d72a983aa6cd27b7289d47d2d42 openldap-2.4.23-34.el6_5.1.x86_64.rpm
ca6194ef492b2e1c193c80d84f0103570c878e5a19007b631d21350cbeceb92d openldap-clients-2.4.23-34.el6_5.1.x86_64.rpm
f4e3a08cb06c1c7442b176cabcd3f2dc3f9a2d7eaebae1cf0a927a2065ebad17 openldap-devel-2.4.23-34.el6_5.1.i686.rpm
44f458b7ddd91937668fc183dea40c6204a5837de35d26301d9a8c872fe4ca8e openldap-devel-2.4.23-34.el6_5.1.x86_64.rpm
42fe4524d0a74da980db54284b506b2a97a3753b6ba971c90694d5176aba5381 openldap-servers-2.4.23-34.el6_5.1.x86_64.rpm
915b474fe581b42c960562f078926899ba437333a78012610e85d6efbff16a15 openldap-servers-sql-2.4.23-34.el6_5.1.x86_64.rpm
Source:
0260ef91950e6c640ab0399d17d22f7a6658916a8409f97f75f381710bbd8bd6 openldap-2.4.23-34.el6_5.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos(a)irc.freenode.net
------------------------------
Message: 3
Date: Tue, 4 Feb 2014 05:36:08 +0000
From: Johnny Hughes <johnny(a)centos.org>
Subject: [CentOS-announce] CEBA-2014:0125 CentOS 6 tigervnc Update
To: centos-announce(a)centos.org
Message-ID: <20140204053608.GA49772(a)n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2014:0125
Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0125.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
11180f5ea56476c6a5a7dff53aeee0c3dc054346312950b9ed431aa38045097e tigervnc-1.1.0-8.el6_5.i686.rpm
12cd6349f8d16539b6580eaaffbfe59af7b26ca27083bfa5305290e299dbfb00 tigervnc-server-1.1.0-8.el6_5.i686.rpm
9b10dab6c2925c3ede850bf842580bbc4fe5f154325b477c3161fa7fd88893ef tigervnc-server-applet-1.1.0-8.el6_5.noarch.rpm
e6f5988b2a2392f27e28beb3faadeaf4623cb1f2a7359fbbd45fee05ba8a2db2 tigervnc-server-module-1.1.0-8.el6_5.i686.rpm
x86_64:
e3baf476de9b2366f466419c798402537aa7f26b66658e7c334d9e3cb87d8a4f tigervnc-1.1.0-8.el6_5.x86_64.rpm
606bf9bdd96eac93db1bb17b7433a1d06ab4de53af6e2e9c62745b4598a525a8 tigervnc-server-1.1.0-8.el6_5.x86_64.rpm
9b10dab6c2925c3ede850bf842580bbc4fe5f154325b477c3161fa7fd88893ef tigervnc-server-applet-1.1.0-8.el6_5.noarch.rpm
e971b66241ac9a736e0c2d2ab2db2f8ca4aa41cf1d28dc285a90771d9bb93c68 tigervnc-server-module-1.1.0-8.el6_5.x86_64.rpm
Source:
1bc4aeb1d6878af61b4ae7544adc985a039467229db3cb2f767a9a54f8c94492 tigervnc-1.1.0-8.el6_5.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos(a)irc.freenode.net
------------------------------
_______________________________________________
CentOS-announce mailing list
CentOS-announce(a)centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 108, Issue 2
***********************************************
A member of the scientific-linux-users(a)fnal.gov wrote:
On 01/14/2014 04:19 PM, George Shaffer wrote:
> > If anyone has gotten password hash rounds using hash_rounds_min and
> > hash_rounds_max in libuser.conf, or the counter part in login.defs
> > (SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS), to work on any RHEL related
> > distribution, I would appreciate knowing how you did it, because this does
> > not seem to work as the documentation I've found says it should. I know
> > the crypt method must be SHA256 or SHA512.
>
> This has an additional PAM setting that might be pertinent.
> http://blog.myconan.net/posts/3567
Thank you. This is just what I needed. The hash rounds control is now working, mostly. At the maximum rounds setting it took 14 to 19 seconds depending on which PC I was on. I needed to bring the delay down to around 1 to 2 seconds.
It's not working as the documentation describes. With both libuser.conf and login.defs set to ranges of 900000000 to 999000000 and pam.d/password-auth-ac set to 900000000, the actual rounds on both SL and CentOS were 9999999 or < 1.1% of what it should have been. This doesn't matter to me, as I need it faster, not slower. In pam.d/ both password-auth and system-auth are links to password-auth-ac and system-auth-ac respectively. These files clearly state:
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
which is sometimes, but not always true. If a rounds number remains in both password-auth and system-auth after authconfig --updateall is run, that is the number which is used, except the maximum value is 9999999 and not 999999999. I got 1000000 to work on both SL 6.3 and CentOS 5.10, and authentication took just about 2 seconds on both systems. On CentOS 5.10 I could find no PAM documentation anywhere that described the rounds option; I had to rely entirely on the brief blog brought to my attention by the S-L-users list member. On SL 6.3 the PAM rounds option is documented in man 8 pam_unix. If I'm reading this correctly, the proper file to edit would be /etc/pam.d/login where the line "password sufficient pam_unix.so sha512 rounds=1000000 shadow nullok try_first_pass use_authtok" should be added.
Password hash rounds control seems to be almost unused. I got no responses in the CentOS 5 Security forum or on the general CentOS email list.
People do not seem to understand how important this can be to password security. According to the oclHashcat (hashcat.net) documentation on the fastest GPU enabled PC they have tested, they get 797 million CPS (cracks per second) against SHA512. If the super fast PC is compared to the single CPU PC with no GPU, using the only algorithm common to all tests (NTLM), there is a speed difference of 1981 times. This suggests roughly 400,000 CPS against SHA512 on the single CPU PC they tested. (Each hashing algorithm interacts differently with the various hardware test configurations, so using one algorithm to estimate how another will perform on a different machine is only a crude estimate. Below, the numbers are discussed like reliable estimates, but until empirical evidence establishes the actual rates in a specific situation, none are reliable.)
The Hashcat single CPU machine has an AMD Phenom II X6 1090T clocked at 3.8 GHz. The test times of single CPU PCs without GPUs are relevant because the GPU enabled, oclHashcat, cannot run a simple dictionary word list with no transformations. oclHashcat must have, brute force characters added to either or both ends of the words in a list. To run a list of the 10,000 most common passwords, without transformations, you need to use the single CPU Hashcat or the deprecated GPU oclHashcat-plus. It seems there is no efficient way to make use of a massively parallel architecture using a simple word list.
oclHashcat also cannot process the "Rule-based Attack" which corresponds with the transformations found in John the Ripper. Again one must use the single CPU Hashcat or the deprecated oclHashcat-plus. So, oclHashcat is blindingly fast with a GPU on brute force and related attacks but cannot process the most obvious dictionary or do the most productive transformations of a dictionary containing real words and names. The most productive transformation is checking the first character, and only the first character, for upper and lower case, in combination with appending 1, 2, or 3 digits to the end of the word. The third digit would be very low yield compared to the first, but still very high compared to any pure brute force attack. If these issues are indicative of a problem that does not fit well with a massively parallel architecture, and not limitations of the oclHashcat developers, there are significant implications for password security.
Simply put, password hash round controls can be used to deny crackers most of the space where modified dictionary attacks get the weak, but not blatantly bad, passwords. If Hashcat is run against the default configuration of SHA512 on my desktop PC, roughly 240,000 CPS seems plausible. Unless there is a fast implementation of SHA512, the use of 1,000,000 hash rounds, which takes about 2 seconds to authenticate on an AMD Phenom II X6 1090T, should slow the the cracking process down to about 0.5 CPS, or more than a five orders of magnitude difference. A simple list of the 10,000 most common passwords might take perhaps 5.5 hours with a million round SHA512, rather than about 5 seconds against the default SHA512.
On most systems, the top 10,000 passwords, should get 70% to 95% of the passwords. Five hours isn't very long but it's a lot longer than 5 seconds. Where the slowdown really hurts the cracker is in the subsequent runs of reduced efficiency but still productive dictionaries and transformations. One option might be to use the next next million most common passwords. A PC 4 times as fast as the Hashcat single CPU PC should approximate a current, high end PC, and run about 4 CPS against the million rounds SHA512. The million words takes just under 70 hours; that should crack another few percent. Next might be a small 35,000 word dictionary of common names and and mostly common words. The most productive transformations should be both upper and lower case on the first letter, plus 1 through 3 digits appended to the end. That's 77.7 million test passwords taking just about 225 days.
If a PC is 4 times faster than the Hashcat test PC against the standard configurations of SHA512, that is 1.6 million CPS. The million rounds configuration takes 228 days for the first 78.7 million test passwords; the default SHA512 configuration is 49 seconds. One is doable but takes commitment, patience, and resources; the other is trivial. Each successive dictionary plus transformations tends to get larger with a lower positive result rate. Any sane person will stop earlier, with regards to how many dictionaries are used, when they see they are faced with an abnormally high number of hash rounds; it shows up very plainly in the hash, just after the "$6$" as "rounds=1000000".
A two second delay for logins or su's may seem like a lot, but we wait longer many times a day for various computer events, none of which get us the added security that a million rounds on a sound hashing algorithm with good salts gets us. A one to two second delay is quite perceptible. If this is not acceptable, then a target time between 0.1 and 0.2 seconds should not be noticeable, but still imposes a massive penalty on the cracker. This is a security freebie. For a fairly minor configuration change, system administrators can role back cracking times 2 or more decades. They only need to determine what is an acceptable delay for authentication on their systems, and how may hash rounds it takes to get in that range. Decent 8 character passwords become almost uncrackable.
George Shaffer
I and testing command line to up and down ethernet connection.
if I perform following, client can not re-connect.
     ifconfig eth0 down
     ifconfig eth0 up
if I use following, client can re-connect:
     ifconfig eth0 down
     ifup eth0
What difference between "ifconfig up" and "ifup"?
thanks.
Helo,
the solution was now found in dmesg. I/O error for the journal.
dmesg was updated, /var/log/messages not. I think because of read only
file system.
Best regards
Helmut
Helo,
up to 04:02 the root file system was OK. With the logrotate activities
there are messages: read only.
Last entry in /var/log/messages is the sendmail entry from logrotate.
less /etc/mtab gives:
/dev/sda1 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
What has happend?
Is this problem related with
https://bugzilla.redhat.com/show_bug.cgi?id=947149
Best regards
Helmut
--
Viele Grüße
Helmut Drodofsky
Internet XS Service GmbH
Heßbrühlstraße 15
70565 Stuttgart
Geschäftsführung
Dr.-Ing. Roswitha Hahn-Drodofsky
HRB 21091 Stuttgart
USt.ID: DE190582774
Tel. 0711 781941 0
Fax: 0711 781941 79
Mail: info(a)internet-xs.de
www.internet-xs.de
_______________________________________________
CentOS mailing list
CentOS(a)centos.org
http://lists.centos.org/mailman/listinfo/centos
Helo,
up to 04:02 the root file system was OK. With the logrotate activities
there are messages: read only.
Last entry in /var/log/messages is the sendmail entry from logrotate.
less /etc/mtab gives:
/dev/sda1 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
What has happend?
Is this problem related with
https://bugzilla.redhat.com/show_bug.cgi?id=947149
Best regards
Helmut
--
Viele Grüße
Helmut Drodofsky
Internet XS Service GmbH
Heßbrühlstraße 15
70565 Stuttgart
Geschäftsführung
Dr.-Ing. Roswitha Hahn-Drodofsky
HRB 21091 Stuttgart
USt.ID: DE190582774
Tel. 0711 781941 0
Fax: 0711 781941 79
Mail: info(a)internet-xs.de
www.internet-xs.de
Hello to all,
I'm in love with CentOS from several months and I want to contribute to the
project, unfortunately I'm not a developer, so how is possible to
contribute to the project?
Regards,
Fabrizio
hi,
We have, like in the years past, a table at Fosdem and I'd like to get
some tshirts printed to hand out. In the past, the Linux Ninja's and
Beards ones got quite a bit of attention ( and both were not brand
spammy, which is always nice ).
Reaching out to the mailing list for ideas on what we can do this year,
with the caveat that I need to finalise by this weekend if we are to get
anything in by Fosdem.
thanks in advance,
--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc