git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Possible bug reports for git-credential-libsecret
@ 2022-03-18 17:15 ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
  2022-03-18 17:40 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ] @ 2022-03-18 17:15 UTC (permalink / raw)
  To: git

Dear Git Development team

Hi.
Recently, I noted that the vulnerability patch (CVE-2020-5260) for
"git credential" is not applied in the "git-credential-libsecret"
program (./contrib/credential/libsecret/git-credential-libsecret.c).

Actually, I'm not sure whether "git-credential-libsecret" is actually
used. But it can be potentially intimidating, thus it would be good to
apply the same patch of "git credential" to
"git-credential-libsecret".

- Patch for CVE-2020-5260
   * https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b38cfa79e9ab21b

- Similar but not patched code in "git-credential-libsecret"
   * https://github.com/git/git/blob/master/contrib/credential/libsecret/git-credential-libsecret.c#L306-L311
   * When I put the malicious URL in the test code shown in the
CVE-2020-5260 patch into "git-credential-libsecret", it does not
terminate.

Could you please check whether this is an actual bug?

Thank you.
Best regards,
Seunghoon Woo

-- 

Best regards,
Seunghoon Woo
Korea University Dept. of Computer Science and Engineering
Computer & Communication Security Lab.
seunghoonwoo@korea.ac.kr
(+82)10-8147-9308

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Possible bug reports for git-credential-libsecret
  2022-03-18 17:15 Possible bug reports for git-credential-libsecret ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
@ 2022-03-18 17:40 ` Junio C Hamano
  2022-03-18 18:19   ` ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2022-03-18 17:40 UTC (permalink / raw)
  To: ‍우승훈[
	대학원석·박사통합과정수료연구(재학)
	/ 컴퓨터학과 ]
  Cc: git

"‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]"
<seunghoonwoo@korea.ac.kr> writes:

> Recently, I noted that the vulnerability patch (CVE-2020-5260) for
> "git credential" is not applied in the "git-credential-libsecret"
> program (./contrib/credential/libsecret/git-credential-libsecret.c).

The code in credential.c touches the data directly obtained from the
outside world.  It opens a pipe to backends like credential-store
and credential-libsecret and feeds the data that is cleansed by the
code you saw in credential.c::credential_write_item() to these
backends.

What these backends write come from these keyring storage systems.
If you look at other backends in contrib/ and also credential-store
and credential-cache, you'll see similar code to give "username=%s"
and "password=%s" back to us in all of them.

Do you have a reason to suspect that these keyring storage systems
the backends talk with can be as malicious as the data source the
CVE patch tried to protect us against?  If an attacker can already
contaminate the contents of the keyrings these backends read from
and write to, they do not have to use "git credential" as their
attack vector, I would suspect.

So I would think it is natural to expect that the patch you saw is
the only defence you need.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Possible bug reports for git-credential-libsecret
  2022-03-18 17:40 ` Junio C Hamano
@ 2022-03-18 18:19   ` ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
  0 siblings, 0 replies; 4+ messages in thread
From: ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ] @ 2022-03-18 18:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi.

I previously determined that code can cause unexpected behavior because:
  (1) the vulnerable code of "credential.c" patched in CVE-2020-5260
(vulnerability related to newline characters) identically exists in
the "git-credential-libsecret.c" file, and
  (2) the test code (please see below) that should be failed, which
was added in CVE-2020-5260 patch, did not be failed in
git-credential-libsecret.

--- TEST CODE for CVE-2020-5260 ---
test_expect_success 'url parser rejects embedded newlines' '
               test_must_fail git credential fill <<-\EOF
               url=https://one.example.com?%0ahost=two.example.com/
               EOF
---------------------------------------------------

However, as you said, if the data has already been purified from
credential_write_item and then flows to credential-libsecret, it
doesn't seem like a big deal.
Thank you for your response.

Best regards,
Seunghoon Woo

2022년 3월 19일 (토) 오전 2:40, Junio C Hamano <gitster@pobox.com>님이 작성:
>
> "‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]"
> <seunghoonwoo@korea.ac.kr> writes:
>
> > Recently, I noted that the vulnerability patch (CVE-2020-5260) for
> > "git credential" is not applied in the "git-credential-libsecret"
> > program (./contrib/credential/libsecret/git-credential-libsecret.c).
>
> The code in credential.c touches the data directly obtained from the
> outside world.  It opens a pipe to backends like credential-store
> and credential-libsecret and feeds the data that is cleansed by the
> code you saw in credential.c::credential_write_item() to these
> backends.
>
> What these backends write come from these keyring storage systems.
> If you look at other backends in contrib/ and also credential-store
> and credential-cache, you'll see similar code to give "username=%s"
> and "password=%s" back to us in all of them.
>
> Do you have a reason to suspect that these keyring storage systems
> the backends talk with can be as malicious as the data source the
> CVE patch tried to protect us against?  If an attacker can already
> contaminate the contents of the keyrings these backends read from
> and write to, they do not have to use "git credential" as their
> attack vector, I would suspect.
>
> So I would think it is natural to expect that the patch you saw is
> the only defence you need.
>


-- 

Best regards,


Seunghoon Woo

Korea University Dept. of Computer Science and Engineering

Computer & Communication Security Lab.

seunghoonwoo@korea.ac.kr

(+82)10-8147-9308

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Possible bug reports for git-credential-libsecret
@ 2022-03-09 17:53 ‍우승훈[ 대학원석·박사통합과정수료 / 컴퓨터학과 ]
  0 siblings, 0 replies; 4+ messages in thread
From: ‍우승훈[ 대학원석·박사통합과정수료 / 컴퓨터학과 ] @ 2022-03-09 17:53 UTC (permalink / raw)
  To: git

Dear Git Development team

Hi.
Recently, I noted that the vulnerability patch (CVE-2020-5260) for
"git credential" is not applied in the "git-credential-libsecret"
program (./contrib/credential/libsecret/git-credential-libsecret.c).

Actually, I'm not sure whether "git-credential-libsecret" is actually
used. But it can be potentially intimidating, thus it would be good to
apply the same patch of "git credential" to
"git-credential-libsecret".

- Patch for CVE-2020-5260
   * https://github.com/git/git/commit/9a6bbee8006c24b46a85d29e7b38cfa79e9ab21b

- Similar but not patched code in "git-credential-libsecret"
   * https://github.com/git/git/blob/master/contrib/credential/libsecret/git-credential-libsecret.c#L306-L311
   * When I put the malicious URL in the test code shown in the
CVE-2020-5260 patch into "git-credential-libsecret", it does not
terminate.

Could you please check whether this is an actual bug?

Thank you.
Best regards,
Seunghoon Woo
-- 

Best regards,

Seunghoon Woo
Korea University Dept. of Computer Science and Engineering
Computer & Communication Security Lab.
seunghoonwoo@korea.ac.kr
(+82)10-8147-9308

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-03-18 18:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-18 17:15 Possible bug reports for git-credential-libsecret ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
2022-03-18 17:40 ` Junio C Hamano
2022-03-18 18:19   ` ‍우승훈[ 대학원석·박사통합과정수료연구(재학) / 컴퓨터학과 ]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-09 17:53 ‍우승훈[ 대학원석·박사통합과정수료 / 컴퓨터학과 ]

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).