Re: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question
Hello, my backup via butc is broken and I am not able to get an actual butc binary for Solaris 10 sparc (sun4x_510). The last binary to download is 1.6.10 and my tries to compile the source of 1.6.23 all fails or the result isn't valid (core dumps) :( Is there anyone who can send me the 1.6.23 butc binary for Solaris 10 on sparc? My binary is significant less then the others -rwxr-xr-x 1 root root 987288 Oct 17 13:28 butc-1.6.23 -rwxr-xr-x 1 root root 2819684 Oct 15 2014 butc-1.6.10 -rwxr-xr-x 1 root root 2808324 Apr 10 2014 butc-1.6.7 And core dumps ... bash-3.2# /usr/afs/backup/butc -port 0 -debuglevel 2 -localauth Will dump to a file Tape mount callout routine is /usr/afs/backup/mount-afs-backup-file.sh Warning: Unrecognized configuration parameter: UMOUNT /usr/afs/backup/mount-afs-backup-file.sh Operator queries are disabled Segmentation Fault (core dumped) Best regards Thomas Otto On 9/13/18 8:37 PM, Jeffrey Altman wrote: > It is unfortunate that the announcement e-mail included neither a URL to > the https://www.openafs.org/security/ page nor a link to the individual > security advisory text files: > > https://www.openafs.org/pages/security/OPENAFS-SA-2018-001.txt > https://www.openafs.org/pages/security/OPENAFS-SA-2018-002.txt > https://www.openafs.org/pages/security/OPENAFS-SA-2018-003.txt > > In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or > 'afsbackup' as it is installed on some systems) must be at least: > > * AuriStorFS v0.175 > * OpenAFS 1.8.2 > * OpenAFS 1.6.23 > > The version of the vlserver, buserver and volserver does not matter. > Those services already supported authenticated and potentially encrypted > connections. > > The underlying cause of the incompatibility is that the 'butc' service > would only accept unauthenticated (rxnull) connections and therefore the > 'backup' command could only create unauthenticated (rxnull) connections > even if the 'backup' command was executed with -localauth. > > As of the releases above, the 'butc' service (by default) will not only > accept authenticated connections but will require that the authenticated > identity be a super-user as reported by the butc host's "bos listusers" > command. > > There is no incompatibility with vlserver, buserver and volserver > because those services already accepted authenticated connections and > required that authenticated identities be super-users in order to > create, read, modify, or delete sensitive information. > > The privilege escalation is due to 'butc' accepting unauthenticated > requests and executing them using a super-user identity when contacting > the vlserver, buserver, and volserver. > > I cannot stress enough how important it is for sites that are running > the AFS backup suite to immediately: > > . upgrade all instances of 'butc' and 'backup'. > > . firewall the 'butc' ports from all machines except those from >which 'backup' is expected to be issued from. The butc port is >(7021 + butc port offset)/udp. The default offset is 0. > > Otherwise, an anonymous attacker can read, alter or destroy the content > of any volume in the cell as well as any backups that do not require > manual intervention by a system administrator to gain access to. > > AuriStor coordinated the release of these changes with the OpenAFS > Security officer(s) because this privilege escalation is not only > remotely exploitable but compromises the security and integrity of all > data stored within an AFS cell that operates a Backup Tape Controller > (butc) instance. > > The AuriStorFS v0.175 release extends the AuriStorFS security model to > backup with the use of AES256-CTS-HMAC-SHA1-96 wire encryption for all > volume data communications and the use of volume security policies to > ensure that volumes cannot be restored to a fileserver with an > incompatible security policy. > > Jeffrey Altman > AuriStor, Inc. > > > On 9/13/2018 3:12 AM, Giovanni Bracco wrote: >> Hello everybody! >> >> I have read about the butc & backup security update. >> >> We run daily the AFS backup and I would like to understand if I need >> just to update the backup server with the new butc/backup modules or I >> need also to update all our file servers in order to match the new >> security improvements connected to backup. >> >> Giovanni >> >> On 11/09/2018 21:04, Benjamin Kaduk wrote: >>> >>> OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility >>> as part of the in-tree backup system, but is of high severity for >>> those sites which are affected -- an anonymous attacker could replace >>> entire volumes with attacker-controlled contents. >>> >>> The changes to fix OPENAFS-SA-2018-001 require behavior change in both >>> >>> butc(8) and backup(8) to use authenticated connections; old and new >>> versions of these utilities will not interoperate absent specific >>> configuration of the new tool to use the old (insecure)
Re: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question --> why only root?
OK, I understand, thank you!
Giovanni
On 27/09/2018 15:22, Jeffrey Altman wrote:
On 9/27/2018 9:11 AM, Giovanni Bracco wrote:
I have made some tests - ok it works - but I wonder why the key
autentication method is allowed only to root user
-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.
Our backup scripts, which have been running on a dedicated server for
many years, run under a dedicated user with administrative powers.
Why the availability of a admin token is not sufficient to run butc in a
secure way?
Giovanni
A user token can be used to authenticate outgoing connections such as
those from butc to the buserver or the volserver. It cannot be used to
authenticate incoming connections to butc from the backup coordinator
command ("backup" or "afsbackup" depending upon the packaging.)
The privilege escalation attack is possible because of butc accepting
unauthenticated "anonymous" requests that would then result in RPCs
being issued as a privileged identity to the buserver and the volserver.
To close the security hole butc must authenticate all incoming RPCs.
To do so butc must have knowledge of the cell-wide key because without
knowledge of that key it cannot decrypt the AFS token presented by the
RPC issuer.
Jeffrey Altman
--
Giovanni Bracco
phone +39 351 8804788
E-mail giovanni.bra...@enea.it
WWW http://www.afs.enea.it/bracco
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question --> why only root?
On 9/27/2018 9:11 AM, Giovanni Bracco wrote:
> I have made some tests - ok it works - but I wonder why the key
> autentication method is allowed only to root user
>
>> -localauth
>> All butc RPCs require superuser authentication.
>> This option must be run as root, and server key material must be present.
>
> Our backup scripts, which have been running on a dedicated server for
> many years, run under a dedicated user with administrative powers.
>
> Why the availability of a admin token is not sufficient to run butc in a
> secure way?
>
> Giovanni
A user token can be used to authenticate outgoing connections such as
those from butc to the buserver or the volserver. It cannot be used to
authenticate incoming connections to butc from the backup coordinator
command ("backup" or "afsbackup" depending upon the packaging.)
The privilege escalation attack is possible because of butc accepting
unauthenticated "anonymous" requests that would then result in RPCs
being issued as a privileged identity to the buserver and the volserver.
To close the security hole butc must authenticate all incoming RPCs.
To do so butc must have knowledge of the cell-wide key because without
knowledge of that key it cannot decrypt the AFS token presented by the
RPC issuer.
Jeffrey Altman
<>
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question --> why only root?
I have made some tests - ok it works - but I wonder why the key autentication method is allowed only to root user > -localauth > All butc RPCs require superuser authentication. > This option must be run as root, and server key material must be present. Our backup scripts, which have been running on a dedicated server for many years, run under a dedicated user with administrative powers. Why the availability of a admin token is not sufficient to run butc in a secure way? Giovanni On 13/09/2018 22:51, Mark Vitale wrote: On Sep 13, 2018, at 2:37 PM, Jeffrey Altman wrote: In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or 'afsbackup' as it is installed on some systems) must be at least: * AuriStorFS v0.175 * OpenAFS 1.8.2 * OpenAFS 1.6.23 As of the releases above, the 'butc' service (by default) will not only accept authenticated connections but will require that the authenticated identity be a super-user as reported by the butc host's "bos listusers" command. A small correction: the OpenAFS 'butc' does not do this by default. Instead, it forces the operator to specify one of the following options: -localauth All butc RPCs require superuser authentication. This option must be run as root, and server key material must be present. -allow_unauthenticated All butc RPCs remain unauthenticated. Regards, -- Mark Vitale mvit...@sinenomine.net -- Giovanni Bracco phone +39 351 8804788 E-mail giovanni.bra...@enea.it WWW http://www.afs.enea.it/bracco ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question
> On Sep 13, 2018, at 2:37 PM, Jeffrey Altman wrote: > > In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or > 'afsbackup' as it is installed on some systems) must be at least: > > * AuriStorFS v0.175 > * OpenAFS 1.8.2 > * OpenAFS 1.6.23 > > > > As of the releases above, the 'butc' service (by default) will not only > accept authenticated connections but will require that the authenticated > identity be a super-user as reported by the butc host's "bos listusers" > command. A small correction: the OpenAFS 'butc' does not do this by default. Instead, it forces the operator to specify one of the following options: -localauth All butc RPCs require superuser authentication. This option must be run as root, and server key material must be present. -allow_unauthenticated All butc RPCs remain unauthenticated. Regards, -- Mark Vitale mvit...@sinenomine.net ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available --> butc & backup security update question
It is unfortunate that the announcement e-mail included neither a URL to the https://www.openafs.org/security/ page nor a link to the individual security advisory text files: https://www.openafs.org/pages/security/OPENAFS-SA-2018-001.txt https://www.openafs.org/pages/security/OPENAFS-SA-2018-002.txt https://www.openafs.org/pages/security/OPENAFS-SA-2018-003.txt In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or 'afsbackup' as it is installed on some systems) must be at least: * AuriStorFS v0.175 * OpenAFS 1.8.2 * OpenAFS 1.6.23 The version of the vlserver, buserver and volserver does not matter. Those services already supported authenticated and potentially encrypted connections. The underlying cause of the incompatibility is that the 'butc' service would only accept unauthenticated (rxnull) connections and therefore the 'backup' command could only create unauthenticated (rxnull) connections even if the 'backup' command was executed with -localauth. As of the releases above, the 'butc' service (by default) will not only accept authenticated connections but will require that the authenticated identity be a super-user as reported by the butc host's "bos listusers" command. There is no incompatibility with vlserver, buserver and volserver because those services already accepted authenticated connections and required that authenticated identities be super-users in order to create, read, modify, or delete sensitive information. The privilege escalation is due to 'butc' accepting unauthenticated requests and executing them using a super-user identity when contacting the vlserver, buserver, and volserver. I cannot stress enough how important it is for sites that are running the AFS backup suite to immediately: . upgrade all instances of 'butc' and 'backup'. . firewall the 'butc' ports from all machines except those from which 'backup' is expected to be issued from. The butc port is (7021 + butc port offset)/udp. The default offset is 0. Otherwise, an anonymous attacker can read, alter or destroy the content of any volume in the cell as well as any backups that do not require manual intervention by a system administrator to gain access to. AuriStor coordinated the release of these changes with the OpenAFS Security officer(s) because this privilege escalation is not only remotely exploitable but compromises the security and integrity of all data stored within an AFS cell that operates a Backup Tape Controller (butc) instance. The AuriStorFS v0.175 release extends the AuriStorFS security model to backup with the use of AES256-CTS-HMAC-SHA1-96 wire encryption for all volume data communications and the use of volume security policies to ensure that volumes cannot be restored to a fileserver with an incompatible security policy. Jeffrey Altman AuriStor, Inc. On 9/13/2018 3:12 AM, Giovanni Bracco wrote: > Hello everybody! > > I have read about the butc & backup security update. > > We run daily the AFS backup and I would like to understand if I need > just to update the backup server with the new butc/backup modules or I > need also to update all our file servers in order to match the new > security improvements connected to backup. > > Giovanni > > On 11/09/2018 21:04, Benjamin Kaduk wrote: >> >> OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility >> as part of the in-tree backup system, but is of high severity for >> those sites which are affected -- an anonymous attacker could replace >> entire volumes with attacker-controlled contents. >> >> The changes to fix OPENAFS-SA-2018-001 require behavior change in both >> >> butc(8) and backup(8) to use authenticated connections; old and new >> versions of these utilities will not interoperate absent specific >> configuration of the new tool to use the old (insecure) behavior. >> These changes also are expected to cause backup(8)'s interactive mode >> to be limited to only butc connections requiring (or not requiring) >> authentication within a given interactive session, based on the initial >> arguments selected. >> >> Bug reports should be filed to openafs-b...@openafs.org. >> >> Benjamin Kaduk >> for the OpenAFS Guardians >> > <> smime.p7s Description: S/MIME Cryptographic Signature
