Re: acme-client canary corrupted issue

2022-12-14 Thread Theo Buehler
> Try this

ok tb

> 
> Index: revokeproc.c
> ===
> RCS file: /home/cvs/src/usr.sbin/acme-client/revokeproc.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 revokeproc.c
> --- revokeproc.c  22 Nov 2021 08:26:08 -  1.19
> +++ revokeproc.c  14 Dec 2022 14:16:46 -
> @@ -239,6 +239,7 @@ revokeproc(int fd, const char *certfile,
>   goto out;
>   }
>   force = 2;
> + continue;
>   }
>   if (found[j]++) {
>   if (revocate) {
> 



Re: acme-client canary corrupted issue

2022-12-14 Thread Renaud Allard



On 12/14/22 15:56, Otto Moerbeek wrote:

On Wed, Dec 14, 2022 at 03:51:44PM +0100, Renaud Allard wrote:




On 12/14/22 14:44, Theo de Raadt wrote:

sysctl kern.nosuidcoredump=3

mkdir /var/crash/acme-client

and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)



Thanks

I have been able to reproduce it reliably with the staging API, however,
there is no core dump generated in /var/crash/acme-client.

To reproduce it, you need a certificate with alternative names using
multiple different domains. Generate a cert, then fully remove one of the
domains and ask for a forced reissue.

I tried with following Otto patch from today, and it seems it solves the
issue.


Are you sure you attached the right patch?

-Otto



Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.23
diff -u -p -r1.23 acctproc.c
--- acctproc.c  14 Jan 2022 09:20:18 -  1.23
+++ acctproc.c  14 Dec 2022 11:06:45 -
@@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc

rc = 1;
  out:
+   ECDSA_SIG_free(ec_sig);
EVP_MD_CTX_free(ctx);
free(pay);
free(sign);





OK, with both patches (one from Otto and the other from Theo B (sorry I 
mistaken the first patch author)) and 4 tries, I have not got the crash 
anymore.


Index: revokeproc.c
===
RCS file: /home/cvs/src/usr.sbin/acme-client/revokeproc.c,v
retrieving revision 1.19
diff -u -p -r1.19 revokeproc.c
--- revokeproc.c22 Nov 2021 08:26:08 -  1.19
+++ revokeproc.c14 Dec 2022 14:16:46 -
@@ -239,6 +239,7 @@ revokeproc(int fd, const char *certfile,
goto out;
}
force = 2;
+   continue;
}
if (found[j]++) {
if (revocate) {



smime.p7s
Description: S/MIME Cryptographic Signature


Re: acme-client canary corrupted issue

2022-12-14 Thread Renaud Allard



On 12/14/22 15:56, Otto Moerbeek wrote:

On Wed, Dec 14, 2022 at 03:51:44PM +0100, Renaud Allard wrote:




On 12/14/22 14:44, Theo de Raadt wrote:

sysctl kern.nosuidcoredump=3

mkdir /var/crash/acme-client

and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)



Thanks

I have been able to reproduce it reliably with the staging API, however,
there is no core dump generated in /var/crash/acme-client.

To reproduce it, you need a certificate with alternative names using
multiple different domains. Generate a cert, then fully remove one of the
domains and ask for a forced reissue.

I tried with following Otto patch from today, and it seems it solves the
issue.


Are you sure you attached the right patch?

-Otto




Ahh, that's a strange one. On the first run, the crash didn't happen 
anymore with that patch, but I retried again to be sure and the crash is 
still there.
I will try again with your "continue" patch too, and make 3 tries to be 
sure.

Would a ktrace help?




Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.23
diff -u -p -r1.23 acctproc.c
--- acctproc.c  14 Jan 2022 09:20:18 -  1.23
+++ acctproc.c  14 Dec 2022 11:06:45 -
@@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc

rc = 1;
  out:
+   ECDSA_SIG_free(ec_sig);
EVP_MD_CTX_free(ctx);
free(pay);
free(sign);





smime.p7s
Description: S/MIME Cryptographic Signature


Re: acme-client canary corrupted issue

2022-12-14 Thread Otto Moerbeek
On Wed, Dec 14, 2022 at 03:51:44PM +0100, Renaud Allard wrote:

> 
> 
> On 12/14/22 14:44, Theo de Raadt wrote:
> > sysctl kern.nosuidcoredump=3
> > 
> > mkdir /var/crash/acme-client
> > 
> > and then try to reproduce, and see if a core file is delivered there.
> > This coredump mechanism was added to capture some hard-to-capture coredumps,
> > you can see more info in core(5) and sysctl(3)
> > 
> 
> Thanks
> 
> I have been able to reproduce it reliably with the staging API, however,
> there is no core dump generated in /var/crash/acme-client.
> 
> To reproduce it, you need a certificate with alternative names using
> multiple different domains. Generate a cert, then fully remove one of the
> domains and ask for a forced reissue.
> 
> I tried with following Otto patch from today, and it seems it solves the
> issue.

Are you sure you attached the right patch?

-Otto

> 
> Index: acctproc.c
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 acctproc.c
> --- acctproc.c14 Jan 2022 09:20:18 -  1.23
> +++ acctproc.c14 Dec 2022 11:06:45 -
> @@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc
> 
>   rc = 1;
>  out:
> + ECDSA_SIG_free(ec_sig);
>   EVP_MD_CTX_free(ctx);
>   free(pay);
>   free(sign);




Re: acme-client canary corrupted issue

2022-12-14 Thread Renaud Allard



On 12/14/22 14:44, Theo de Raadt wrote:

sysctl kern.nosuidcoredump=3

mkdir /var/crash/acme-client

and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)



Thanks

I have been able to reproduce it reliably with the staging API, however, 
there is no core dump generated in /var/crash/acme-client.


To reproduce it, you need a certificate with alternative names using 
multiple different domains. Generate a cert, then fully remove one of 
the domains and ask for a forced reissue.


I tried with following Otto patch from today, and it seems it solves the 
issue.


Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.23
diff -u -p -r1.23 acctproc.c
--- acctproc.c  14 Jan 2022 09:20:18 -  1.23
+++ acctproc.c  14 Dec 2022 11:06:45 -
@@ -439,6 +439,7 @@ op_sign(int fd, EVP_PKEY *pkey, enum acc

rc = 1;
 out:
+   ECDSA_SIG_free(ec_sig);
EVP_MD_CTX_free(ctx);
free(pay);
free(sign);


smime.p7s
Description: S/MIME Cryptographic Signature


Re: acme-client canary corrupted issue

2022-12-14 Thread Otto Moerbeek
On Wed, Dec 14, 2022 at 12:30:25PM +0100, Renaud Allard wrote:

> Hi Otto,
> 
> 
> On 12/14/22 12:01, Otto Moerbeek wrote:
> > On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote:
> > 
> > > Hello,
> > > 
> > > I was force renewing some certs because I removed some domains from
> > > the cert, and got this:
> > > acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 
> > > 0xb0@0xb0
> > > 
> > > I am using vm.malloc_conf=SUR>>
> > > 
> > > Best Regards
> > 
> > 
> > I cannot reproduce with several attempts. Please include details on
> > platform and version.
> > 
> > Can you show a run with -v on? That gives a hint where the problem
> > occurs.
> > 
> > Do you get a core dump? If so, try to get a backtrace.
> > 
> 
> 
> It's quite hard to reproduce, I only had it once when I shrank the
> alternative names involved in one certificate. There was no core dump.
> 
> This was produced on 7.2-stable amd64
> account and domain keys are ecdsa
> 
> I ran it with -vvF and could get my run log thanks to tmux back buffer.
> I will skip all the verification/certs babble
> 
> isildur# acme-client -vvF arnor.org
> 
> acme-client: /somewhere/arnor.org.key: loaded domain key
> 
> acme-client: /etc/acme/letsencrypt-privkey.pem: loaded account key
> 
> acme-client: /somewhere/arnor.org.crt: certificate valid: 74 days left
> 
> acme-client: /somewhere/arnor.org.crt: domain list changed, forcing renewal
> acme-client: https://acme-v02.api.letsencrypt.org/directory: directories
> 
> acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248
> 
>  lots of standard certs/verif dialog *
> -END CERTIFICATE- ] (5800 bytes)
> 
> acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0
> acme-client: /somewhere/arnor.org.crt: created
> 
> acme-client: /somewhere/arnor.org.fullchain.pem: created
> 
> acme-client: signal: revokeproc(53931): Abort trap
> 
> Best Regards


Try this

-Otto

Index: revokeproc.c
===
RCS file: /home/cvs/src/usr.sbin/acme-client/revokeproc.c,v
retrieving revision 1.19
diff -u -p -r1.19 revokeproc.c
--- revokeproc.c22 Nov 2021 08:26:08 -  1.19
+++ revokeproc.c14 Dec 2022 14:16:46 -
@@ -239,6 +239,7 @@ revokeproc(int fd, const char *certfile,
goto out;
}
force = 2;
+   continue;
}
if (found[j]++) {
if (revocate) {



Re: acme-client canary corrupted issue

2022-12-14 Thread Theo de Raadt
sysctl kern.nosuidcoredump=3

mkdir /var/crash/acme-client

and then try to reproduce, and see if a core file is delivered there.
This coredump mechanism was added to capture some hard-to-capture coredumps,
you can see more info in core(5) and sysctl(3)

Renaud Allard  wrote:

> Hi Otto,
> 
> 
> On 12/14/22 12:01, Otto Moerbeek wrote:
> > On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote:
> > 
> >> Hello,
> >>
> >> I was force renewing some certs because I removed some domains from
> >> the cert, and got this:
> >> acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 
> >> 0xb0@0xb0
> >>
> >> I am using vm.malloc_conf=SUR>>
> >>
> >> Best Regards
> > I cannot reproduce with several attempts. Please include details on
> > platform and version.
> > Can you show a run with -v on? That gives a hint where the problem
> > occurs.
> > Do you get a core dump? If so, try to get a backtrace.
> > 
> 
> 
> It's quite hard to reproduce, I only had it once when I shrank the
> alternative names involved in one certificate. There was no core dump.
> 
> This was produced on 7.2-stable amd64
> account and domain keys are ecdsa
> 
> I ran it with -vvF and could get my run log thanks to tmux back buffer.
> I will skip all the verification/certs babble
> 
> isildur# acme-client -vvF arnor.org acme-client:
> /somewhere/arnor.org.key: loaded domain key acme-client:
> /etc/acme/letsencrypt-privkey.pem: loaded account key acme-client:
> /somewhere/arnor.org.crt: certificate valid: 74 days left acme-client:
> /somewhere/arnor.org.crt: domain list changed, forcing renewal
> acme-client: https://acme-v02.api.letsencrypt.org/directory:
> directories acme-client: acme-v02.api.letsencrypt.org: DNS:
> 172.65.32.248  lots of standard certs/verif dialog *
> -END CERTIFICATE- ] (5800 bytes) acme-client(53931) in free():
>  chunk canary corrupted 0xa06cb09db00 0xb0@0xb0
> acme-client: /somewhere/arnor.org.crt: created acme-client:
> /somewhere/arnor.org.fullchain.pem: created acme-client: signal:
> revokeproc(53931): Abort trap
> 
> Best Regards



Re: acme-client canary corrupted issue

2022-12-14 Thread Renaud Allard

Hi Otto,


On 12/14/22 12:01, Otto Moerbeek wrote:

On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote:


Hello,

I was force renewing some certs because I removed some domains from
the cert, and got this:
acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0

I am using vm.malloc_conf=SUR>>

Best Regards



I cannot reproduce with several attempts. Please include details on
platform and version.

Can you show a run with -v on? That gives a hint where the problem
occurs.

Do you get a core dump? If so, try to get a backtrace.




It's quite hard to reproduce, I only had it once when I shrank the 
alternative names involved in one certificate. There was no core dump.


This was produced on 7.2-stable amd64
account and domain keys are ecdsa

I ran it with -vvF and could get my run log thanks to tmux back buffer.
I will skip all the verification/certs babble

isildur# acme-client -vvF arnor.org 

acme-client: /somewhere/arnor.org.key: loaded domain key 

acme-client: /etc/acme/letsencrypt-privkey.pem: loaded account key 

acme-client: /somewhere/arnor.org.crt: certificate valid: 74 days left 

acme-client: /somewhere/arnor.org.crt: domain list changed, forcing 
renewal
acme-client: https://acme-v02.api.letsencrypt.org/directory: directories 

acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 


 lots of standard certs/verif dialog *
-END CERTIFICATE- ] (5800 bytes) 

acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 
0xb0@0xb0
acme-client: /somewhere/arnor.org.crt: created 

acme-client: /somewhere/arnor.org.fullchain.pem: created 


acme-client: signal: revokeproc(53931): Abort trap

Best Regards


smime.p7s
Description: S/MIME Cryptographic Signature


Re: acme-client canary corrupted issue

2022-12-14 Thread Otto Moerbeek
On Tue, Dec 13, 2022 at 10:34:53AM +0100, Renaud Allard wrote:

> Hello,
> 
> I was force renewing some certs because I removed some domains from
> the cert, and got this:
> acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0
> 
> I am using vm.malloc_conf=SUR>>
> 
> Best Regards


I cannot reproduce with several attempts. Please include details on
platform and version.

Can you show a run with -v on? That gives a hint where the problem
occurs.

Do you get a core dump? If so, try to get a backtrace.

-Otto



acme-client canary corrupted issue

2022-12-13 Thread Renaud Allard

Hello,

I was force renewing some certs because I removed some domains from
the cert, and got this:
acme-client(53931) in free(): chunk canary corrupted 0xa06cb09db00 0xb0@0xb0

I am using vm.malloc_conf=SUR>>

Best Regards


smime.p7s
Description: S/MIME Cryptographic Signature