commit a33cb937ba5dc4c60c9dc7ac61d9796f0a96755f Author: Benjamin Kaduk Date: Mon Sep 10 22:18:34 2018 -0500 Make OpenAFS 1.8.2 Update version strings for the 1.8.2 release. Change-Id: I90e59f3a8c930d80eab46b405050e11ea2fc2fe1 commit aecb8aef7074910838d639d75f46e5515baffc35 Author: Benjamin Kaduk Date: Mon Sep 10 20:26:20 2018 -0500 Update NEWS for 1.8.2 Release notes for the OpenAFS 1.8.2 security release. Change-Id: If447b08cc3b3901da22eeb92a2e75bf2ab476633 commit 90601818205aeefd1cf99b8766a7bfd03bf9b96a Author: Benjamin Kaduk Date: Tue Sep 11 10:51:01 2018 -0500 Fix typos in audit format strings Commit 9ebff4c6caa8b499d999cfd515d4d45eb3179769 introduced audit framework support for several butc-related data types, but had a typo ('$d' for '%d') in a couple of places, that was not reported by compiler format-string checking. Fix the typo to properly print all the auditable data. (cherry picked from commit d5816fd6cd1876760a985a817dbbb3940cf3bddb) Change-Id: Iaea64ab0fe422381c298d94eff201c3525bd00c2 commit ed217df4b23e111d4b12e7236bdf6f8ab5575952 Author: Benjamin Kaduk Date: Sun Sep 9 10:44:38 2018 -0500 OPENAFS-SA-2018-001 backup: use authenticated connection to butc Use the standard routine to pick a client security object, instead of always assuming rxnull. Respect -localauth as well as being able to use the current user's tokens, but also provide a -nobutcauth argument to fall back to the historical rxnull behavior (but only for the connections to butc; vldb and budb connections are not affected). (cherry picked from commit 345ee34236c08a0a2fb3fff016edfa18c7af4b0a) Change-Id: I1e5e0e38d4003020db5875609db08194f7684bb7 commit 1b199eeafad6420982380ce5e858f00c528cfd13 Author: Benjamin Kaduk Date: Thu Sep 6 18:50:39 2018 -0500 OPENAFS-SA-2018-001 butc: require authenticated connections with -localauth The butc -localauth option is available to use the cell-wide key to authenticate to the vlserver and buserver, which in normal deployments will require incoming connections to be authenticated as a superuser. In such cases, the cell-wide key is also available for use in authenticating incoming connections to the butc, which would otherwise have been completely unauthenticated. Because of the security hazards of allowing unauthenticaed inbound RPCs, especially ones that manipulate backup information and are allowed to initiate outboud RPCs authenticated as the superuser, default to not allowing unauthenticated inbound RPCs at all. Provide an opt-out command-line argument for deployments that require this functionality and have configured their network environment (firewall/etc.) appropriately. Change-Id: Ia6349757a4c6d59d1853df1a844e210d32c14feb commit 6f8c0c8134de1b5358ec56878e350aeab31aa3cd Author: Benjamin Kaduk Date: Sun Sep 9 11:49:03 2018 -0500 OPENAFS-SA-2018-001 Add auditing to butc server RPC implementations Make the actual implementations into helper functions, with the RPC stubs calling the helpers and doing the auditing on the results, akin to most other server programs in the tree. This relies on support for some additional types having been added to the audit framework. (cherry picked from commit c43169fd36348783b1a5a55c5bb05317e86eef82) Change-Id: Ia90c355bfded24820ae3b5c014e948e28eac6356 commit 41d2dd569a365465ac47da3cd39eceba4beaeaf3 Author: Benjamin Kaduk Date: Sat Sep 8 19:42:36 2018 -0500 OPENAFS-SA-2018-001 audit: support butc types Add support for several complex butc types to enable butc auditing. Change-Id: I6aedd933cf5330cda40aae6f33827ae65409df32 commit 7eb650a6edd96e3c7e68f170945ddcdac8b67975 Author: Benjamin Kaduk Date: Sat Sep 8 20:35:25 2018 -0500 OPENAFS-SA-2018-001 butc: remove dummy osi_audit() routine This local stub was present in the original IBM import and is unused. It will conflict with the real audit code once we start adding auditing to the TC_ RPCs, so remove it now. (cherry picked from commit 50216dbbc30ed94f89bdd0e964f4891e87f28c0b) Change-Id: I63db513bb107ef47da77f13b27cdf5d24b4a24b4 commit 2cf5cfa8561047e855fed9ab35d1a041e309e39a Author: Mark Vitale Date: Fri Jul 6 03:14:19 2018 -0400 OPENAFS-SA-2018-003 rxgen: prevent unbounded input arrays RPCs with unbounded arrays as inputs are susceptible to remote denial-of-service (DOS) attacks. A malicious client may submit an RPC request with an arbitrarily large array, forcing the server to expend large amounts of network bandwidth, cpu cycles, and heap memory to unmarshal the input. Instead, issue an error message and stop rxgen when it detects an RPC defined with an unbounded input array. Thus we will detect the problem at build time and prevent any future unbounded input arrays. (cherry picked from commit a4c1d5c48deca2ebf78b1c90310b6d56b3d48af6) Change-Id: I4c60c4776d7f02ea9790b76b49e7325d9c55f31d commit fe41fa565be6e325da75f3e9b8fbdac2c521b027 Author: Mark Vitale Date: Fri Jul 6 03:21:26 2018 -0400 OPENAFS-SA-2018-003 volser: prevent unbounded input to various AFSVol* RPCs Several AFSVol* RPCs are defined with an unbounded XDR "string" as input. RPCs with unbounded arrays as inputs are susceptible to remote denial-of-service (DOS) attacks. A malicious client may submit an AFSVol* request with an arbitrarily large string, forcing the volserver to expend large amounts of network bandwidth, cpu cycles, and heap memory to unmarshal the input. Instead, give each input "string" an appropriate size. Volume names are inherently capped to 32 octets (including trailing NUL) by the protocol, but there is less clearly a hard limit on partition names. The Vol_PartitionInfo{,64} functions accept a partition name as input and also return a partition name in the output structure; the output values have wire-protocol limits, so larger values could not be retrieved by clients, but for denial-of-service purposes, a more generic PATH_MAX-like value seems appropriate. We have several varying sources of such a limit in the tree, but pick 4k as the least-restrictive. [kaduk@mit.edu: use a larger limit for pathnames and expand on PATH_MAX in commit message] (cherry picked from commit 8b92d015ccdfcb70c7acfc38e330a0475a1fbe28) Change-Id: Ifa591dfd861688d4d7eb43145b29a1739c6e0f6f commit fac3749f0d180e0ca229326c0e8568a60e17d3e9 Author: Mark Vitale Date: Fri Jul 6 01:09:53 2018 -0400 OPENAFS-SA-2018-003 volser: prevent unbounded input to AFSVolForwardMultiple AFSVolForwardMultiple is defined with an input parameter that is defined to XDR as an unbounded array of replica structs: typedef replica manyDests<>; RPCs with unbounded arrays as inputs are susceptible to remote denial-of-service (DOS) attacks. A malicious client may submit an AFSVolForwardMultiple request with an arbitrarily large array, forcing the volserver to expend large amounts of network bandwidth, cpu cycles, and heap memory to unmarshal the input. Even though AFSVolForwardMultiple requires superuser authorization, this attack is exploitable by non-authorized actors because XDR unmarshalling happens long before any authorization checks can occur. Add a bounding constant (NMAXNSERVERS 13) to the manyDests input array. This constant is derived from the current OpenAFS vldb implementation, which is limited to 13 replica sites for a given volume by the layout (size) of the serverNumber, serverPartition, and serverFlags fields. [kaduk@mit.edu: explain why this constant is used] (cherry picked from commit 97b0ee4d9c9d069e78af2e046c7987aa4d3f9844) Change-Id: I49945ce1fd5979eadf6d5b310dc6d8c68f6f8dc7 commit 87f199c14199afa29f75bb336383564f0fb4548a Author: Mark Vitale Date: Thu Jul 5 23:51:37 2018 -0400 OPENAFS-SA-2018-003 budb: prevent unbounded input to BUDB_SaveText BUDB_SaveText is defined with an input parameter that is defined to XDR as an unbounded array of chars: typedef char charListT<>; RPCs with unbounded arrays as inputs are susceptible to remote denial-of-service (DOS) attacks. A malicious client may submit a BUDB_SaveText request with an arbitrarily large array, forcing the budb server to expend large amounts of network bandwidth, cpu cycles, and heap memory to unmarshal the input. Modify the XDR definition of charListT so it is bounded. This typedef is shared (as an OUT parameter) by BUDB_GetText and BUDB_DumpDB, but fortunately all in-tree callers of the client routines specify the same maximum length of 1024. Note: However, SBUDB_SaveText server implementation seems to allow for up to BLOCK_DATA_SIZE (2040) = BLOCKSIZE (2048) - sizeof(struct blockHeader) (8), and it's unknown if any out-of-tree callers exist. Since we do not need a tight bound in order to avoid the DoS, use a somewhat higher maximum of 4096 bytes to leave a safety margin. [kaduk@mit.edu: bump the margin to 4096; adjust commit message to match] (cherry picked from commit 124445c0c47994f5e2efef30e86337c3c8ebc93f) Change-Id: Ic34f8f9e7484b7503a223509d5d61b72e1298b35 commit 4218dc0a2db75c740d1d31966e672f85ad7999bd Author: Mark Vitale Date: Thu Jul 5 21:11:30 2018 -0400 OPENAFS-SA-2018-003 vlserver: prevent unbounded input to VL_RegisterAddrs VL_RegisterAddrs is defined with an input argument of type bulkaddrs, which is defined to XDR as an unbounded array of afs_uint32 (IPv4 addresses): typedef afs_uint32 bulkaddrs<> The <> with no value instructs rxgen to build client and server stubs that allow for a maximum size of "~0u" or 0xFFFFFFFF. Ostensibly the bulkaddrs array is unbounded to allow it to be shared among VL_RegisterAddrs, VL_GetAddrs, and VL_GetAddrsU. The VL_GetAddrs* RPCs use bulkaddrs as an output array with a maximum size of MAXSERVERID (254). VL_RegisterAddrss uses bulkaddrs as an input array, with a nominal size of VL_MAXIPADDRS_PERMH (16). However, RPCs with unbounded array inputs are susceptible to remote denial-of-service attacks. That is, a malicious client may send a VL_RegisterAddrs request with an arbitrarily long array, forcing the vlserver to expend large amounts of network bandwidth, cpu cycles, and heap memory to unmarshal the argument. Even though VL_RegisterAddrs requires superuser authorization, this attack is exploitable by non-authorized actors because XDR unmarshalling happens long before any authorization checks can occur. Because all uses of the type that our implementation support have fixed bounds on valid data (whether input or output), apply an arbitrary implementation limit (larger than any valid structure would be), to prevent this class of attacks in the XDR decoder. [kaduk@mit.edu: limit the bulkaddrs type instead of introducing a new type] (cherry picked from commit 7629209219bbea3f127b33be06ac427ebc3a559e) Change-Id: I1726a834eb98b7e06285bac78a74e20bbedb9ce8 commit 418b2ab56c60e44375df31a3a8f77461d577a5ff Author: Benjamin Kaduk Date: Thu Aug 30 10:38:56 2018 -0500 OPENAFS-SA-2018-002 butc: Initialize OUT scalar value In STC_ReadLabel, the interaction with the tape device is synchronous, so there is no need to allocate a task ID for status monitoring. However, we do need to initialize the output value, to avoid writing stack garbage on the wire. (cherry picked from commit f5a80115f8f7f9418287547f0fc7fdb13d936f00) Change-Id: I3f5ea1cfff0d04adb49cdca7b05ac869665660e5 commit 0ee86cc3f986365df9de21ede5735cc1f40db7e5 Author: Mark Vitale Date: Tue Jun 26 06:01:16 2018 -0400 OPENAFS-SA-2018-002 ubik: prevent VOTE_Debug, VOTE_XDebug information leak VOTE_Debug and VOTE_XDebug (udebug) both leave a single field uninitialized if there is no current transaction. This leaks the memory contents of the ubik server over the wire. struct ubik_debug - 4 bytes in member writeTrans In common code to both RPCs, ensure that writeTrans is always initialized. [kaduk@mit.edu: switch to memset] (cherry picked from commit 7a7c1f751cdb06c0d95339c999b2c035c2d2168b) Change-Id: I2759989bf1a5190f9f03621218224c47094a88b7 commit c912830e9c82d91bccf85018ef1e6a75edc410c4 Author: Mark Vitale Date: Tue Jun 26 05:26:21 2018 -0400 OPENAFS-SA-2018-002 kaserver: prevent KAM_ListEntry information leak KAM_ListEntry (kas list) does not initialize its output correctly. It leaks kaserver memory contents over the wire: struct kaindex - up to 64 bytes for member name - up to 64 bytes for member instance Initialize the buffer. [kaduk@mit.edu: move initialization to top of server routine] (cherry picked from commit b604ee7add7be416bf20973422a041e913d20761) Change-Id: Ic40bb2d5af409399c11a378340ba92174e26112f commit 43b3efd4f8cd3227b2b24ff673adeb834f6a3f0b Author: Mark Vitale Date: Tue Jun 26 05:12:32 2018 -0400 OPENAFS-SA-2018-002 butc: prevent TC_DumpStatus, TC_ScanStatus information leaks TC_ScanStatus (backup status) and TC_GetStatus (internal backup status watcher) do not initialize their output buffers. They leak memory contents over the wire: struct tciStatusS - up to 64 bytes in member taskName (TC_MAXNAMELEN 64) - up to 64 bytes in member volumeName " Initialize the buffers. [kaduk@mit.edu: move initialization to top of server routines] (cherry picked from commit be0142707ca54f3de99c4886530e7ac9f48dd61c) Change-Id: I7a97ad1dbab004938085b401929d4925d80ff3b2 commit b7e53b9e9706d63215a1804ed9eca30d69461f03 Author: Mark Vitale Date: Tue Jun 26 05:00:25 2018 -0400 OPENAFS-SA-2018-002 butc: prevent TC_ReadLabel information leak TC_ReadLabel (backup readlabel) does not initialize its output buffer completely. It leaks butc memory contents over the wire: struct tc_tapeLabel - up to 32 bytes from member afsname (TC_MAXTAPELEN 32) - up to 32 bytes from member pname (TC_MAXTAPELEN 32) Initialize the buffer. [kaduk@mit.edu: move initialization to the RPC stub] (cherry picked from commit 52f4d63148323e7d605f9194ff8c1549756e654b) Change-Id: Ia5d9dd649bdbd45c8b201f344bf55080a55e3392 commit 6f26a945adeca87b669282eed0eaca3dca0a1423 Author: Mark Vitale Date: Tue Jun 26 04:39:44 2018 -0400 OPENAFS-SA-2018-002 budb: prevent BUDB_* information leaks The following budb RPCs do not initialize their output correctly. This leaks buserver memory contents over the wire: BUDB_FindLatestDump (backup dump) BUDB_FindDump (backup volrestore, diskrestore, volsetrestore) BUDB_GetDumps (backup dumpinfo) BUDB_FindLastTape (backup dump) struct budb_dumpEntry - up to 32 bytes in member volumeSetName - up to 256 bytes in member dumpPath - up to 32 bytes in member name - up to 32 bytes in member tape.tapeServer - up to 32 bytes in member tape.format - up to 256 bytes in member dumper.name - up to 128 bytes in member dumper.instance - up to 256 bytes in member dumper.cell Initialize the buffer in common routine FillDumpEntry. (cherry picked from commit e96771471134102d3879a0ac8b2c4ef9d91a61b8) Change-Id: I85ec8a21966386baa8243326072e5730726cba96 commit a6557ffa64d8fab3526c4f89629dcbb965a27780 Author: Mark Vitale Date: Tue Jun 26 03:56:24 2018 -0400 OPENAFS-SA-2018-002 afs: prevent RXAFSCB_TellMeAboutYourself information leak RXAFSCB_TellMeAboutYourself does not completely initialize its output buffers. This leaks kernel memory over the wire: struct interfaceAddr Unix cache manager (libafs) - up to 124 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 * 4) - 4)) - up to 124 bytes in array subnetmask " - up to 124 bytes in array mtu " Windows cache manager - 64 bytes in array addr_in ((AFS_MAX_INTERFACE_ADDR 32 - CM_MAXINTERFACE_ADDR 16)* 4) - 64 bytes in array subnetmask " - 64 bytes in array mtu " The following implementations of SRXAFSCB_TellMeAboutYourself are not susceptible: - fsprobe - libafscp - xstat_fs_test Initialize the buffer. (cherry picked from commit 211b6d6a4307006da1467b3be46912a3a5d7b20b) Change-Id: I2fee5cc9c11ea42726c7c8f9a7d14eafee6142f0 commit 3dea4adaa356b7eed40b6162c106c5e90690f5a1 Author: Mark Vitale Date: Tue Jun 26 03:47:41 2018 -0400 OPENAFS-SA-2018-002 afs: prevent RXAFSCB_GetLock information leak RXAFSCB_GetLock (cmdebug) does not correctly initialize its output. This leaks kernel memory over the wire: struct AFSDBLock - up to 14 bytes for member name (16 - '\0') Initialize the buffer. (cherry picked from commit b52eb11a08f2ad786238434141987da27b81e743) Change-Id: If84c5d9d805356cd56be77313149a931a948b4d5 commit e19ad4cdde463d2bbb4b815525da992bd5fc2648 Author: Mark Vitale Date: Tue Jun 26 03:37:37 2018 -0400 OPENAFS-SA-2018-002 ptserver: prevent PR_ListEntries information leak PR_ListEntries (pts listentries) does not properly initialize its output buffers. This leaks ptserver memory over the wire: struct prlistentries - up to 62 bytes for each entry name (PR_MAXNAMELEN 64 - 'a\0') Initialize the buffer, and remove the now redundant memset for the reserved fields. (cherry picked from commit 9d1aeb5d761581a35bef2042e9116b96e9ae3bf5) Change-Id: I679c205502941891cbb34f10e648a6f9d83c3c60 commit 2d22756de7af2c72b8aca6969825f8e921f01d6c Author: Mark Vitale Date: Tue Jun 26 03:00:02 2018 -0400 OPENAFS-SA-2018-002 volser: prevent AFSVolMonitor information leak AFSVolMonitor (vos status) does not properly initialize its output buffers. This leaks information from volserver memory: struct transDebugInfo - up to 29 bytes in member lastProcName (30-'\0') - 16 bytes in members readNext, tranmitNext, lastSendTime, lastReceiveTime Initialize the buffers. This must be done on a per-buffer basis inside the loop, since realloc is used to expand the storage if needed, and there is not a standard realloc API to zero the newly allocated storage. [kaduk@mit.edu: update commit message] (cherry picked from commit 26924fd508b21bb6145e77dc31b6cd0923193b72) Change-Id: Id10aa1f4d0b8694f6d85468d743c2fc2a8102339 commit 28edf734db08d3a8285e89d9d78aa21db726e4c7 Author: Mark Vitale Date: Tue Jun 26 02:33:05 2018 -0400 OPENAFS-SA-2018-002 volser: prevent AFSVolPartitionInfo(64) information leak AFSVolPartitionInfo and AFSVolPartitionInfo64 (vos partinfo) do not properly initialize their reply buffers. This leaks the contents of volserver memory over the wire: AFSVolPartitionInfo (struct diskPartition) - up to 24 bytes in member name (32-'/vicepa\0')) - up to 12 bytes in member devName (32-'/vicepa/Lock/vicepa\0')) AFSVolPartitionInfo64 (struct diskPartition64) - up to 248 bytes in member name (256-'/vicepa\0')) - up to 236 bytes in member devName (256-'/vicepa/Lock/vicepa\0') Initialize the output buffers. [kaduk@mit.edu: move memset to top-level function scope of RPC handlers] (cherry picked from commit 76e62c1de868c2b2e3cc56a35474e15dc4cc1551) Change-Id: I041b91873a38a2af40f5b0a00b70cc87634f25c8 commit c8c8682bb0e84ee5289fac3063119ae524773f61 Author: Mark Vitale Date: Mon Jun 25 18:03:12 2018 -0400 OPENAFS-SA-2018-002 ptserver: prevent PR_IDToName information leak SPR_IDToName does not completely initialize the return array of names, and thus leaks information from ptserver memory: - up to 62 bytes per requested id (PR_MAXNAMELEN 64 - 'a\0') Use calloc to ensure that all memory sent on the wire is initialized, preventing the information leak. [kaduk@mit.edu: switch to calloc; update commit message] (cherry picked from commit 70b0136d552a0077d3fae68f3aebacd985abd522) Change-Id: I787fc26ecb6fa64b17f8579198793903bc4eb16d