auth/cephx: ignore CEPH_ENTITY_TYPE_AUTH in requested keys

When handling CEPHX_GET_AUTH_SESSION_KEY requests from nautilus+
clients, ignore CEPH_ENTITY_TYPE_AUTH in CephXAuthenticate::other_keys.
Similarly, when handling CEPHX_GET_PRINCIPAL_SESSION_KEY requests,
ignore CEPH_ENTITY_TYPE_AUTH in CephXServiceTicketRequest::keys.
These fields are intended for requesting service tickets, the auth
ticket (which is really a ticket granting ticket) must not be shared
this way.

Otherwise we end up sharing an auth ticket that a) isn't encrypted
with the old session key even if needed (should_enc_ticket == true)
and b) has the wrong validity, namely auth_service_ticket_ttl instead
of auth_mon_ticket_ttl.  In the CEPHX_GET_AUTH_SESSION_KEY case, this
undue ticket immediately supersedes the actual auth ticket already
encoded in the same reply (the reply frame ends up containing two auth
tickets).

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 05772ab6127bdd9ed2f63fceef840f197ecd9ea8)

This only applies part of the patch, as the
CephXAuthenticate::other_keys handling isn't present in this version.

Origin: upstream, https://github.com/ceph/ceph/commit/05b3b6a305ddbb56cc53bbeadf5866db4d785f49

Gbp-Pq: Name CVE-2021-20288.patch

rgw: RGWSwiftWebsiteHandler::is_web_dir checks empty subdir_name

checking for empty name avoids later assertion in RGWObjectCtx::set_atomic

Fixes: CVE-2021-3531
Reviewed-by: Casey Bodley <cbodley@redhat.com>
Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 7196a469b4470f3c8628489df9a41ec8b00a5610)

Origin: upstream, https://github.com/ceph/ceph/commit/f44a8ae8aa27ecef69528db9aec220f12492810e

Gbp-Pq: Name CVE-2021-3531.patch

rgw: sanitize \r in s3 CORSConfiguration's ExposeHeader

follows up on 1524d3c0c5cb11775313ea1e2bb36a93257947f2 to escape \r as
well

Fixes: CVE-2021-3524
Reported-by: Sergey Bobrov <Sergey.Bobrov@kaspersky.com>
Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 87806f48e7a1b8891eb90711f1cedd26f1119aac)

Origin: upstream, https://github.com/ceph/ceph/commit/763aebb94678018f89427137ffbc0c5205b1edc1

Gbp-Pq: Name CVE-2021-3524.patch

tasks/cephfs/test_volume_client: Add tests for authorize/deauthorize

1. Add testcase for authorizing auth_id which is not added by
   ceph_volume_client
2. Add testcase to test 'allow_existing_id' option
3. Add testcase for deauthorizing auth_id which has got it's caps
   updated out of band

Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit aa4beb3d993649a696af95cf27150cc460baaf70)

Conflicts:
qa/tasks/cephfs/test_volume_client.py

Origin: upstream, https://github.com/ceph/ceph/commit/a036cf3cbf47bbc8fd7793a80767c1257ed426d1

Gbp-Pq: Name CVE-2020-27781-5.patch

pybind/ceph_volume_client: Optionally authorize existing auth-ids

Optionally allow authorizing auth-ids not created by ceph_volume_client
via the option 'allow_existing_id'. This can help existing deployers
of manila to disallow/allow authorization of pre-created auth IDs
via a manila driver config that sets 'allow_existing_id' to False/True.

Fixes: https://tracker.ceph.com/issues/48555
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 77b42496e25cbd4af2e80a064ddf26221b53733f)

Origin: upstream, https://github.com/ceph/ceph/commit/ae1889014e5becb774b69ca52ed7465a33873a3f

Gbp-Pq: Name CVE-2020-27781-4.patch

pybind/ceph_volume_client: Preserve existing caps while authorize/deauthorize auth-id

Authorize/Deauthorize used to overwrite the caps of auth-id which would
end up deleting existing caps. This patch fixes the same by retaining
the existing caps by appending or deleting the new caps as needed.

Fixes: https://tracker.ceph.com/issues/48555
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 47100e528ef77e7e82dc9877424243dc6a7e7533)

Origin: upstream, https://github.com/ceph/ceph/commit/eb2fa6934fc736f8abe6d9e237b0a14c9d877626

Gbp-Pq: Name CVE-2020-27781-3.patch

pybind/ceph_volume_client: Disallow authorize auth_id

This patch disallow the ceph_volume_client to authorize the auth_id
which is not created by ceph_volume_client. Those auth_ids could be
created by other means for other use cases which should not be modified
by ceph_volume_client.

Fixes: https://tracker.ceph.com/issues/48555
Signed-off-by: Ramana Raja <rraja@redhat.com>
Signed-off-by: Kotresh HR <khiremat@redhat.com>
(cherry picked from commit 3a85d2d04028a323952a31d18cdbefb710be2e2b)

Origin: upstream, https://github.com/ceph/ceph/commit/1de5caf2da9b06aa4f363f9706c693213a6ee59f

Gbp-Pq: Name CVE-2020-27781-2.patch

pybind/ceph_volume_client: Fix PEP-8 SyntaxWarning

Signed-off-by: Đặng Minh Dũng <dungdm93@live.com>
(cherry picked from commit 3ce9a89a5a1a2d7fa3d57c597b781a6aece7cbb5)

Origin: upstream, https://github.com/ceph/ceph/commit/7e45e2905f2f61bf9d100308df979f432754982b

Gbp-Pq: Name CVE-2020-27781-1.patch

mon: don't log "config set" and "config-key set" dispatch and finished messages

Signed-off-by: Neha Ojha <nojha@redhat.com>
(cherry picked from commit 4b83dfb1f74e8a59c802ff3c0eb4595f7e763762)

Origin: upstream, https://github.com/ceph/ceph/pull/38614/commits/630f614751d9b0932c21e9ab22f23f883a8fa5e9

Gbp-Pq: Name CVE-2020-25678-2.patch

messages/MMonCommand, MMonCommandAck: don't log values for "config set" and "config-key set"

This acts like a big hammer to avoid adding sensitive information, like passwords
into mon/mgr/cluster logs when using "config set" and "config-key set" to set keys
whose values should be secure.

Fixes: https://tracker.ceph.com/issues/37503
Signed-off-by: Neha Ojha <nojha@redhat.com>
(cherry picked from commit 3d54660ca1a9a7ae54e884c3181fca17a40d8cd3)

Origin: upstream, https://github.com/ceph/ceph/pull/38614/commits/b579cddca07a19d8de2613eb7713de9e33d67d0d

Gbp-Pq: Name CVE-2020-25678-1.patch

rgw: check for tagging element in POST Obj requests

Check for null element when reading the tagging field from POST obj XML

Fixes: https://tracker.ceph.com/issues/44967
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Origin: upstream, https://github.com/ceph/ceph/pull/34715

Gbp-Pq: Name CVE-2020-12059.patch

rgw: sanitize newlines in s3 CORSConfiguration's ExposeHeader

the values in the <ExposeHeader> element are sent back to clients in a
Access-Control-Expose-Headers response header. if the values are allowed
to have newlines in them, they can be used to inject arbitrary response
headers

this issue only affects s3, which gets these values from an xml document

in swift, they're given in the request header
X-Container-Meta-Access-Control-Expose-Headers, so the value itself
cannot contain newlines

Signed-off-by: Casey Bodley <cbodley@redhat.com>
Reported-by: Adam Mohammed <amohammed@linode.com>
Origin: upstream, https://github.com/ceph/ceph/pull/35773

Gbp-Pq: Name CVE-2020-10753.patch

rgw: reject control characters in response-header actions

S3 GetObject permits overriding response header values, but those inputs
need to be validated to insure only characters that are valid in an HTTP
header value are present.

Credit: Initial vulnerability discovery by William Bowling (@wcbowling)
Credit: Further vulnerability discovery by Robin H. Johnson <rjohnson@digitalocean.com>
Signed-off-by: Robin H. Johnson <rjohnson@digitalocean.com>
Origin: upstream, https://github.com/ceph/ceph/pull/34504/commits/9ca5b3628245e2878426602bb24f1a4e45edc850

Gbp-Pq: Name CVE-2020-1760-3.patch

rgw: EPERM to ERR_INVALID_REQUEST

As per Robin's comments and S3 spec

Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Origin: upstream, https://github.com/ceph/ceph/pull/34504/commits/607a65fccd8a80c2f2c74853a6dc5c14ed8a75c1

Gbp-Pq: Name CVE-2020-1760-2.patch

rgw: reject unauthenticated response-header actions

Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Reviewed-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit d8dd5e513c0c62bbd7d3044d7e2eddcd897bd400)

Origin: upstream, https://github.com/ceph/ceph/pull/34504/commits/ba0790a01ba5252db1ebc299db6e12cd758d0ff9

Gbp-Pq: Name CVE-2020-1760-1.patch

rgw: improve beast

Avoid leaking connections that had partially-consumed
client data on unexpected disconnect.

Resolves CVE-2020-1700 (moderate impact flaw).

Fixes: https://tracker.ceph.com/issues/42531
Signed-off-by: Or Friedmann <ofriedma@redhat.com>
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Origin: upstream, https://github.com/ceph/ceph/commit/ff72c50a2c43c57aead933eb4903ad1ca6d1748a

Gbp-Pq: Name CVE-2020-1700.patch

rgw: asio: check the remote endpoint before processing requests

`socket.remote_endpoint()` can throw exceptions corresponding to errors in the
`getpeername` syscall, make sure these are handled.

Fixes: CVE-2019-10222, https://tracker.ceph.com/issues/40018
Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
Origin: upstream, https://github.com/ceph/ceph/commit/6171399fdedd928b4249d135b4036e3de25079aa

Gbp-Pq: Name CVE-2019-10222.patch

[PATCH] rgw: fix radosgw linkage with WITH_RADOSGW_BEAST_FRONTEND=OFF

The master commit 5c040d991510cb4ff0d74305889130e2d84fedc1 fixing issue
http://tracker.ceph.com/issues/23680 was backported to luminous for v12.2.11 by
a47e714e7f5ce803ba7d8986c5d954123b85fc8e which was included in
https://github.com/ceph/ceph/pull/24621, where it came as the first of a series
of five cherry-picks.

This, it turns out, was the wrong order - it should have come last since it
was a follow-up fix.

Signed-off-by: Nathan Cutler <ncutler@suse.com>
(partial manual backport of 5c040d991510cb4ff0d74305889130e2d84fedc1)

Gbp-Pq: Name radosgw-linkage-without-beast.patch

Fix for build failures on 32bit architectures

Origin: other, https://kojipkgs.fedoraproject.org//packages/ceph/12.2.11/1.fc29/src/ceph-12.2.11-1.fc29.src.rpm
Forwarded: no
Last-Update: 2019-02-18

Last-Update: 2019-02-18
Gbp-Pq: Name 32-bit-ftbfs.patch

softfp-armel

Gbp-Pq: Name softfp-armel.patch

boost-1.67-fixes

Gbp-Pq: Name boost-1.67-fixes.patch

[PATCH] librbd: Do not instantiate TrimRequest template class

We include TrimRequest.cc in librbd tests at two places:
 - operation/test_mock_TrimRequest.cc
 - operation/test_mock_ResizeRequest.cc

That causes linking errors when doing the builds because some of the
instantiated classes are defined twice.

We can fix this by not instantiating the template class in the
TrimReqeust.cc file when including it in the tests.

Signed-off-by: Boris Ranto <branto@redhat.com>
Gbp-Pq: Name armhf-ftbfs.patch

fix-var-run-perms-sysvinit

Gbp-Pq: Name fix-var-run-perms-sysvinit.patch

[PATCH 3/3] Core-local statistics

Summary:
This diff changes `StatisticsImpl` from a thread-local approach to a core-local one. The goal is to perform faster aggregations, particularly for applications that have many threads. There should be no behavior change.
Closes https://github.com/facebook/rocksdb/pull/2258

Differential Revision: D5016258

Pulled By: ajkr

fbshipit-source-id: 7d4d165b4a91d8110f0409d113d1be91f22d31a9
(cherry picked from commit ac39d6bec5b2c23a2c3fd0f0e61d468be4f3e803)

Gbp-Pq: Name 0003-Core-local-statistics.patch

[PATCH 2/3] core-local array type conversions

Summary:
try to clean up the type conversions and hope it passes on windows.

one interesting thing I learned is that bitshift operations are special: in `x << y`, the result type depends only on the type of `x`, unlike most arithmetic operations where the result type depends on both operands' types.
Closes https://github.com/facebook/rocksdb/pull/2277

Differential Revision: D5050145

Pulled By: ajkr

fbshipit-source-id: f3309e77526ac9612c632bf93a62d99757af9a29
(cherry picked from commit bbe9ee7dd4a542b191ace521ca13b4bdb063008b)

Gbp-Pq: Name 0002-core-local-array-type-conversions.patch

[PATCH 1/3] CoreLocalArray class

Summary:
Moved the logic for core-local array out of ConcurrentArena and into a separate class because I want to reuse it for core-local stats.
Closes https://github.com/facebook/rocksdb/pull/2256

Differential Revision: D5011518

Pulled By: ajkr

fbshipit-source-id: a75a7b8f7b7a42fd6273489ada405f14c6be196a
(cherry picked from commit cda5fde2d96624df38afc7f02b6b3e699648c62d)

Gbp-Pq: Name 0001-CoreLocalArray-class.patch

Mark intention fallthroughs for i386 codepaths

Forwarded: https://github.com/facebook/rocksdb/pull/2700

Gbp-Pq: Name rocksdb-fallthrough-i386.patch

libatomic

Gbp-Pq: Name libatomic.patch

Ask virtualenv to never download anything

Last-Update: 2014-10-31
Forwarded: no

Gbp-Pq: Name virtualenv-never-download.patch

remove ceph.com ref to favicon

Origin: backport, https://github.com/ceph/ceph/commit/409b8923a24ff557c53260842aaff6400054bc9b

Gbp-Pq: Name 0013-remove-ceph.com-ref-to-favicon.patch

fix various spelling errors

Forwarded: https://github.com/ceph/ceph/pull/20831

Gbp-Pq: Name 0010-fix-various-spelling-errors.patch

ceph (12.2.11+dfsg1-2.1+deb10u1) buster-security; urgency=medium

  * Non-maintainer upload by the LTS Security Team.

  [ Stefano Rivera ]
  * Collection of minor security updates for Ceph.
  * CVE-2020-27781: Privilege Escalation: User credentials could be manipulated
    and stolen by Native CephFS consumers of OpenStack Manila, resulting in
    potential privilege escalation. An Open Stack Manila user can request
    access to a share to an arbitrary cephx user, including existing users.
    The access key is retrieved via the interface drivers. Then, all users of
    the requesting OpenStack project can view the access key. This enables the
    attacker to target any resource that the user has access to. This can be
    done to even "admin" users, compromising the ceph administrator.
  * CVE-2021-20288: Potential Privilege Escalation: When handling
    CEPHX_GET_PRINCIPAL_SESSION_KEY requests, ignore CEPH_ENTITY_TYPE_AUTH in
    CephXServiceTicketRequest::keys.
  * CVE-2020-1760: XSS: A flaw was found in the Ceph Object Gateway, where it
    supports request sent by an anonymous user in Amazon S3. This flaw could
    lead to potential XSS attacks due to the lack of proper neutralization of
    untrusted input.
  * CVE-2020-25678: Information Disclosure: ceph stores mgr module passwords
    in clear text. This can be found by searching the mgr logs for grafana and
    dashboard, with passwords visible.
  * CVE-2019-10222: Denial of service: An unauthenticated attacker could crash
    the Ceph RGW server by sending valid HTTP headers and terminating the
    connection, resulting in a remote denial of service for Ceph RGW clients.
  * CVE-2020-10753 and CVE-2021-3524: Header Injection: It was possible to
    inject HTTP headers via a CORS ExposeHeader tag in an Amazon S3 bucket. The
    newline character in the ExposeHeader tag in the CORS configuration file
    generates a header injection in the response when the CORS request is
    made.
  * CVE-2020-12059: Denial of Service: A POST request with an invalid tagging
    XML could crash the RGW process by triggering a NULL pointer exception.
  * CVE-2020-1700: Denial of Service: A flaw was found in the way the Ceph RGW
    Beast front-end handles unexpected disconnects. An authenticated attacker
    can abuse this flaw by making multiple disconnect attempts resulting in a
    permanent leak of a socket connection by radosgw. This flaw could lead to
    a denial of service condition by pile up of CLOSE_WAIT sockets, eventually
    leading to the exhaustion of available resources, preventing legitimate
    users from connecting to the system.
  * CVE-2021-3531: Denial of Service: When processing a GET Request in Ceph
    Storage RGW for a swift URL that ends with two slashes it could cause the
    rgw to crash, resulting in a denial of service.
  * CVE-2021-3979: Loss of Confidentiality: A key length flaw was found in
    Ceph Storage. An attacker could exploit the fact that the key length is
    incorrectly passed in an encryption algorithm to create a non random key,
    which is weaker and can be exploited for loss of confidentiality and
    integrity on encrypted disks.

  [ Bastien Roucariès ]

  * CVE-2023-43040: A flaw was found in Ceph RGW. An unprivileged
    user can write to any bucket(s) accessible by a given key
    if a POST's form-data contains a key called 'bucket'
    with a value matching the name of the bucket used to sign
    the request. The result of this is that a user could actually
    upload to any bucket accessible by the specified access key
    as long as the bucket in the POST policy matches the bucket
    in said POST form part. (Closes: #1053690)

[dgit import unpatched ceph 12.2.11+dfsg1-2.1+deb10u1]

Import ceph_12.2.11+dfsg1-2.1+deb10u1.debian.tar.xz

[dgit import tarball ceph 12.2.11+dfsg1-2.1+deb10u1 ceph_12.2.11+dfsg1-2.1+deb10u1.debian.tar.xz]

Import ceph_12.2.11+dfsg1.orig.tar.xz

[dgit import orig ceph_12.2.11+dfsg1.orig.tar.xz]