Re: [CentOS] CentOS 6 fix sudo CVE-2021-3156

[Christian Anthon]

Centos-6 compatible packages are available from the official sudo 
webpage. It's a later version of sudo and I'm not sure if that will 
cause problems. I've tried installing it and so-far so-good.


https://www.sudo.ws/download.html

Cheers, Christian.

On 27/01/2021 08.38, Gionatan Danti wrote:

Hi all,
do you know if a fix for sudo CVE-2021-3156 is available for CentOS 6?

While CentOS 6 is now supported anymore, RedHat has it under its 
payedsupport agreement (see: 
https://access.redhat.com/security/vulnerabilities/RHSB-2021-002).


So I wonder if some community-packaged patch exists...
Thanks.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] repodata out of sync for centos6-updates

[Christian Anthon]

Hi,

I wanted to update the bind package on our centos-6 servers, and the 
package is there for the mirrors I've checked, but the repodata dates 
back from January 18. May be I'm too fast and the repodata update comes 
later. If so how long can it take?


Cheers, Christian.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Fwd: [CentOS-announce] CESA-2017:3200 Important CentOS 6 kernel Security Update

[Christian Anthon]

Found the answer myself. RHBA should of course have been RHSA so the 
correct link is


https://access.redhat.com/errata/RHSA-2017:3200

Cheers, Christian.

On 16-11-2017 09:53, Christian Anthon wrote:
The redhat errata link leads to a 404 page. Anybody know what this is 
about?


Cheers, Christian.



 Forwarded Message 
Subject: [CentOS-announce] CESA-2017:3200 Important CentOS 6 
kernel Security Update

Date: Wed, 15 Nov 2017 21:38:19 +
From: Johnny Hughes <joh...@centos.org>
Reply-To: centos@centos.org
To: centos-annou...@centos.org



CentOS Errata and Security Advisory 2017:3200 Important

Upstream details at : https://access.redhat.com/errata/RHBA-2017:3200

The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )

i386:
5d284bfa08a5793517ec76a246754d2f4645ac012336d27f1c5807380a4e256e 
kernel-2.6.32-696.16.1.el6.i686.rpm
f85553367eece6ba51f2965caecd7ce09aafb0ce62160da55a135cfff6188114 
kernel-abi-whitelists-2.6.32-696.16.1.el6.noarch.rpm
95a65d3b9b1aa4a02457dd53ad321c1118e937d452bd4082498141a7ea20ce7a 
kernel-debug-2.6.32-696.16.1.el6.i686.rpm
3f5383b34f2933c3be876852126b2d577cfc22951f2e7d859b7efc8ce8c239e9 
kernel-debug-devel-2.6.32-696.16.1.el6.i686.rpm
13442b6c43647b8160f8cc15d099f078a6b2550d00b322857c067d82b9cadb6c 
kernel-devel-2.6.32-696.16.1.el6.i686.rpm
2d8b989b7f10dabed4df203bc4989dca906e6acfde39ed24585c22b739926974 
kernel-doc-2.6.32-696.16.1.el6.noarch.rpm
e5b26dc63d1fce0e966b7d5c8695cd7648ac716f93a547963536b09e01ce74f5 
kernel-firmware-2.6.32-696.16.1.el6.noarch.rpm
4f1380ddb2db054ea518d9186c04e4148644f5f4f9c201fcc1a563b9e4ef487f 
kernel-headers-2.6.32-696.16.1.el6.i686.rpm
f04384bf339595bedfdcc7bc008a59968f090bade0a6b8148d9eb22eac4964f5 
perf-2.6.32-696.16.1.el6.i686.rpm
58f5d8fef44bd215d01559cdc53fee903b3f9f6544c67c67fcafd4587d8ca4b1 
python-perf-2.6.32-696.16.1.el6.i686.rpm


x86_64:
9490bf087394c9c7e98444728438ab41ac99a44fbea99e8b22b39f7cebe7b1ca 
kernel-2.6.32-696.16.1.el6.x86_64.rpm
f85553367eece6ba51f2965caecd7ce09aafb0ce62160da55a135cfff6188114 
kernel-abi-whitelists-2.6.32-696.16.1.el6.noarch.rpm
9b754666727e4b8802f448a84279eff3a02285a227af4fa3199ed761798d7965 
kernel-debug-2.6.32-696.16.1.el6.x86_64.rpm
3f5383b34f2933c3be876852126b2d577cfc22951f2e7d859b7efc8ce8c239e9 
kernel-debug-devel-2.6.32-696.16.1.el6.i686.rpm
0da6ec2f05ed53d70b115c475f86b01ddbc11f85fe116127f648316265c565a3 
kernel-debug-devel-2.6.32-696.16.1.el6.x86_64.rpm
2fa496dc3ece90d97886030754340d8dd4f5816c3cad2182de275b1f0007ef75 
kernel-devel-2.6.32-696.16.1.el6.x86_64.rpm
2d8b989b7f10dabed4df203bc4989dca906e6acfde39ed24585c22b739926974 
kernel-doc-2.6.32-696.16.1.el6.noarch.rpm
e5b26dc63d1fce0e966b7d5c8695cd7648ac716f93a547963536b09e01ce74f5 
kernel-firmware-2.6.32-696.16.1.el6.noarch.rpm
6f451f1500fbcefac11541065c607cca80afcd74910dd72b54d8a659826835aa 
kernel-headers-2.6.32-696.16.1.el6.x86_64.rpm
e72ba7452350e398030e8d65bd53830cb003964c1444cc823378db5792b6588b 
perf-2.6.32-696.16.1.el6.x86_64.rpm
ce90fe8a317164248e18390182d9a4d4e1cf60c2aa13fd07d3df53bc8561ea1b 
python-perf-2.6.32-696.16.1.el6.x86_64.rpm


Source:
2909a2f8bd8cda02978aa674da4a7b0fbbabc65d817131193bdd50a11bf60555 
kernel-2.6.32-696.16.1.el6.src.rpm






___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Fwd: [CentOS-announce] CESA-2017:3200 Important CentOS 6 kernel Security Update

[Christian Anthon]

The redhat errata link leads to a 404 page. Anybody know what this is about?

Cheers, Christian.



 Forwarded Message 
Subject: 	[CentOS-announce] CESA-2017:3200 Important CentOS 6 kernel 
Security Update

Date:   Wed, 15 Nov 2017 21:38:19 +
From:   Johnny Hughes 
Reply-To:   centos@centos.org
To: centos-annou...@centos.org



CentOS Errata and Security Advisory 2017:3200 Important

Upstream details at : https://access.redhat.com/errata/RHBA-2017:3200

The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )

i386:
5d284bfa08a5793517ec76a246754d2f4645ac012336d27f1c5807380a4e256e  
kernel-2.6.32-696.16.1.el6.i686.rpm
f85553367eece6ba51f2965caecd7ce09aafb0ce62160da55a135cfff6188114  
kernel-abi-whitelists-2.6.32-696.16.1.el6.noarch.rpm
95a65d3b9b1aa4a02457dd53ad321c1118e937d452bd4082498141a7ea20ce7a  
kernel-debug-2.6.32-696.16.1.el6.i686.rpm
3f5383b34f2933c3be876852126b2d577cfc22951f2e7d859b7efc8ce8c239e9  
kernel-debug-devel-2.6.32-696.16.1.el6.i686.rpm
13442b6c43647b8160f8cc15d099f078a6b2550d00b322857c067d82b9cadb6c  
kernel-devel-2.6.32-696.16.1.el6.i686.rpm
2d8b989b7f10dabed4df203bc4989dca906e6acfde39ed24585c22b739926974  
kernel-doc-2.6.32-696.16.1.el6.noarch.rpm
e5b26dc63d1fce0e966b7d5c8695cd7648ac716f93a547963536b09e01ce74f5  
kernel-firmware-2.6.32-696.16.1.el6.noarch.rpm
4f1380ddb2db054ea518d9186c04e4148644f5f4f9c201fcc1a563b9e4ef487f  
kernel-headers-2.6.32-696.16.1.el6.i686.rpm
f04384bf339595bedfdcc7bc008a59968f090bade0a6b8148d9eb22eac4964f5  
perf-2.6.32-696.16.1.el6.i686.rpm
58f5d8fef44bd215d01559cdc53fee903b3f9f6544c67c67fcafd4587d8ca4b1  
python-perf-2.6.32-696.16.1.el6.i686.rpm

x86_64:
9490bf087394c9c7e98444728438ab41ac99a44fbea99e8b22b39f7cebe7b1ca  
kernel-2.6.32-696.16.1.el6.x86_64.rpm
f85553367eece6ba51f2965caecd7ce09aafb0ce62160da55a135cfff6188114  
kernel-abi-whitelists-2.6.32-696.16.1.el6.noarch.rpm
9b754666727e4b8802f448a84279eff3a02285a227af4fa3199ed761798d7965  
kernel-debug-2.6.32-696.16.1.el6.x86_64.rpm
3f5383b34f2933c3be876852126b2d577cfc22951f2e7d859b7efc8ce8c239e9  
kernel-debug-devel-2.6.32-696.16.1.el6.i686.rpm
0da6ec2f05ed53d70b115c475f86b01ddbc11f85fe116127f648316265c565a3  
kernel-debug-devel-2.6.32-696.16.1.el6.x86_64.rpm
2fa496dc3ece90d97886030754340d8dd4f5816c3cad2182de275b1f0007ef75  
kernel-devel-2.6.32-696.16.1.el6.x86_64.rpm
2d8b989b7f10dabed4df203bc4989dca906e6acfde39ed24585c22b739926974  
kernel-doc-2.6.32-696.16.1.el6.noarch.rpm
e5b26dc63d1fce0e966b7d5c8695cd7648ac716f93a547963536b09e01ce74f5  
kernel-firmware-2.6.32-696.16.1.el6.noarch.rpm
6f451f1500fbcefac11541065c607cca80afcd74910dd72b54d8a659826835aa  
kernel-headers-2.6.32-696.16.1.el6.x86_64.rpm
e72ba7452350e398030e8d65bd53830cb003964c1444cc823378db5792b6588b  
perf-2.6.32-696.16.1.el6.x86_64.rpm
ce90fe8a317164248e18390182d9a4d4e1cf60c2aa13fd07d3df53bc8561ea1b  
python-perf-2.6.32-696.16.1.el6.x86_64.rpm

Source:
2909a2f8bd8cda02978aa674da4a7b0fbbabc65d817131193bdd50a11bf60555  
kernel-2.6.32-696.16.1.el6.src.rpm



--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS

___
CentOS-announce mailing list
centos-annou...@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CVE-2016-5195 DirtyCOW : Critical Linux Kernel Flaw

[Christian Anthon]

On 25-10-2016 15:39, Peter Kjellström wrote:

I can confirm that c6 is vulnerable, we're running a patched kernel
(local build) using a rhel6 adaptation of the upstream fix.

Ask off-list if you want an src.rpm


Thanks,

the srpm would be very helpful, I'll reply off-list.

Cheers, Christian.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CVE-2016-5195 “DirtyCOW”: Critical Linux Kernel Flaw

[Christian Anthon]

What is the best approach on centos 6 to mitigate the problem is 
officially patched? As far as I can tell Centos 6 is vulnerable to 
attacks using ptrace.


There is a mitigation described here

https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

which doesn't fix the underlying problem, but at least protects against 
known attack vectors. However, I'm unsure if the script only applies to 
Centos 7, or if it also works on Centos 6?


Cheers, Christian

On 24-10-2016 18:29, Gilbert Sebenste wrote:

On Sat, 22 Oct 2016, Valeri Galtsev wrote:


On Sat, October 22, 2016 7:49 pm, Valeri Galtsev wrote:

Dear All,

I guess, we all have to urgently apply workaround, following, say, 
this:


https://gryzli.info/2016/10/21/protect-cve-2016-5195-dirtycow-centos-7rhel7cpanelcloudlinux/ 



At least those of us who still have important multi user machines 
running

Linux.


I should have said CentOS 7. Older ones (CentOS 6 and 5) are not 
vulnerable.


Patch is out on RHEL side:

https://rhn.redhat.com/errata/RHSA-2016-2098.html

*** 


Gilbert Sebenste 
(My opinions only!)  
**
*** 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Routing issue

[Christian Anthon]

Sounds like an issue similar to what I experienced when trying to force
all outgoing ssh traffic on a NAT'ed network to go through a particular
interface. I've forgot the details, but running the following on the
firewall helped

for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 0  $f
done

I'm no expert in advanced routing, so if it breaks, you get to keep the
pieces.

Christian.

On 09/26/2012 06:15 PM, Steve Clark wrote:
 Hello,
 
 This is on Centos 6 and not something I think is wrong with Centos 6
 but I am looking to see if anybody else has experienced this and
 if there is solution. So thanks up front for indulging me.
 
 Because Linux makes routing decisions before SNAT it is causing
 problems when trying to use FTP with two upstream providers in
 a load balanced setup.
 
 Other than ftp, things seem to work OK. Below is my setup and tcpdump
 output that shows ftp packets trying to go out the wrong interface.
 
 ip ru sh
 0:  from all lookup local
 200:from y.y.y.174 lookup t1
 201:from x.x.x.217 lookup t2
 32766:  from all lookup main
 32767:  from all lookup default
 
 ip r s
 y.y.y.129 dev eth1  scope link
 172.16.0.0/29 dev gre1  proto kernel  scope link  src 172.16.0.1
 y.y.y.128/25 dev eth1  proto kernel  scope link  src y.y.y.174
 10.0.1.0/24 dev eth0  proto kernel  scope link  src 10.0.1.90
 192.168.198.0/24 dev eth0  proto kernel  scope link  src 192.168.198.92
 x.x.x.0/24 dev eth2  proto kernel  scope link  src x.x.x.217
 10.0.128.0/17 dev eth0  proto kernel  scope link  src 10.0.129.88
 default
   nexthop via y.y.y.129  dev eth1 weight 1
   nexthop via x.x.x.1  dev eth2 weight 1
 
 ip r s tab t1
 default via y.y.y.129 dev eth1  src y.y.y.174
 
 ip r s tab t2
 default via x.x.x.1 dev eth2  src x.x.x.217
 
 Chain PREROUTING (policy ACCEPT 1050K packets, 128M bytes)
pkts bytes target prot opt in out source   
 destination
 
 Chain POSTROUTING (policy ACCEPT 423K packets, 35M bytes)
pkts bytes target prot opt in out source   
 destination
   0 0 ACCEPT all  --  *  eth110.0.1.0/24  
 10.0.0.0/8
   0 0 ACCEPT all  --  *  eth110.0.1.0/24  
 172.16.0.0/12
   0 0 ACCEPT all  --  *  eth110.0.1.0/24  
 192.168.0.0/16
  58  3480 SNAT   all  --  *  eth110.0.1.0/24  
 0.0.0.0/0
to:y.y.y.174
   4   240 SNAT   all  --  *  eth210.0.1.0/24  
 0.0.0.0/0
to:x.x.x.217
 
 lsmod | grep nf_
 nf_conntrack_ipv6   7207  3
 nf_defrag_ipv6  9873  1 nf_conntrack_ipv6
 nf_nat_ftp  2602  0
 nf_nat 18580  2 iptable_nat,nf_nat_ftp
 nf_conntrack_ipv4   7694  6 iptable_nat,nf_nat
 nf_defrag_ipv4  1039  1 nf_conntrack_ipv4
 nf_conntrack_ftp   10475  1 nf_nat_ftp
 nf_conntrack   65524  7
 iptable_nat,nf_conntrack_ipv6,xt_state,nf_nat_ftp,nf_nat,nf_conntrack_ipv4,nf_conntrack_ftp
 ipv6  264769  41
 nf_conntrack_ipv6,nf_defrag_ipv6,ip6table_mangle,ip6_tunnel,tunnel6
 
 connection starts out eth2 - but then subsequent packets that should be
 routed out eth2 are being sent out eth1 see below.
 eth2 x.x.x.217
 tcpdump -nli eth2 host 131.247.254.5
 
 16:23:06.062451 IP x.x.x.217.53651  131.247.254.5.ftp: Flags [S], seq
 1482565198, win 5840, options [mss 1460,sackOK,TS val 423546705 ecr 
 0,nop,wscale
 6], length 0
 16:23:06.076788 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [S.], seq
 740341460, ack 1482565199, win 5792, options [mss 1460,sackOK,TS val 
 2565444838
 ecr 423546705,nop,wscale 7], length 0
 16:23:06.077224 IP x.x.x.217.53651  131.247.254.5.ftp: Flags [.], ack 1, win
 92, options [nop,nop,TS val 423546720 ecr 2565444838], length 0
 16:23:06.096900 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565444858 ecr 423546720], length 96
 16:23:06.316866 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565445077 ecr 423546720], length 96
 16:23:06.764410 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565445515 ecr 423546720], length 96
 16:23:07.634411 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565446391 ecr 423546720], length 96
 16:23:09.394482 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565448143 ecr 423546720], length 96
 16:23:12.886997 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565451647 ecr 423546720], length 96
 16:23:19.892082 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, options [nop,nop,TS val 2565458655 ecr 423546720], length 96
 16:23:33.907303 IP 131.247.254.5.ftp  x.x.x.217.53651: Flags [P.], seq 1:97,
 ack 1, win 46, 

[CentOS] cr repository when running your own mirror

[Christian Anthon]

Hi,

what is the right way to deal with the new cr repository for centos 5 
when you are running your own mirror. In particular the following 
statement I don't fully understand:

- Once 5.7 is released, the 5.6/cr/ repositories will be removed ( they
will not be available on vault.centos.org )


Christian.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos