** Description changed:

  Temporary placeholder: Opening this bug in order to start the SRU
  process. Will prepare updates and testing regime first.
  
- Upstream fix in
+ SRU justification:
+ 
+ [ Impact ]
+ 
+  * ods-enforcerd crashes when it needs to generate a new key, thus
+ rendering OpenDNSSEC installations useless.
+ 
+  * The issue is caused by __snprintf_chk aborting after snprintf() is
+ called with a pointer value that is beyond the start of a malloc()ed
+ buffer, but with the full size of the buffer of the buffer as the second
+ argument. There is no buffer overflow occurring, thus this issue only
+ presents itself when the source is compiled with _FORTIFY_SOURCE=3 (from
+ noble onwards).
+ 
+  * This is very similar to
+ https://bugs.launchpad.net/ubuntu/+source/opendnssec/+bug/2089834, but
+ in a different daemon.
+ 
+  * I have searched for other potential instances of _FORTIFY_SOURCE-
+ impacted functions and there were no others.
+ 
+  * This was fixed by upstream in
  
https://github.com/opendnssec/opendnssec/commit/042eaf5d7c51810ecf1d4f5c9e83d3103a6f771f
+ 
+ [ Test Plan ]
+ 
+  1. Install opendnssec-enforcer and softhsm2 (the --no-insta--recommends are 
so that it doesn't unnecessarily also pull the opendnssec-signer package, but 
isn't strictly necessary):
+    $ sudo apt install --no-install-recommends opendnssec-enforcer softhsm2
+ 
+  2. Give opendnssec user access to softhsm2 tokens directory 
(/var/lib/softhsm/tokens/) via group membership.
+    $ sudo adduser opendnssec softhsm
+ 
+  3. Initialise a new softhsm2 token with PIN '1234' and label 'OpenDNSSEC' 
(please note that this test plan uses the package-provided configuration files 
and the PIN and label are the default values; you can choose other values, but 
these must be reflected in /etc/opendnssec/conf.xml):
+    $ sudo runuser -u opendnssec -- softhsm2-util --init-token --slot 0 
--label 'OpenDNSSEC'
+ 
+  4. Initialise the database (the directory is normally not writable by the 
opendnssec user, make it writable to simplify the testing):
+    $ sudo chmod 770 /var/lib/opendnssec/
+    $ sudo runuser -u opendnssec -- ods-enforcer-db-setup
+ 
+  5. In a separate terminal which should be watched, start the daemon in 
foreground mode:
+    $ sudo runuser -u opendnssec -- ods-enforcerd -d
+ 
+  6. Import the default policy configuration (this command talks to the daemon 
via a unix socket):
+    $ sudo ods-enforcer policy import
+ 
+  7. Create a simple zone file:
+    $ sudo tee /var/lib/opendnssec/unsigned/example.com <<EOF
+ $ORIGIN example.com
+ @ 3600    IN  SOA ns.example.com  admin.cnix.ro. (0 14400 3600 1209600 300)
+ EOF
+ 
+  8. Notice that the daemon is still alive at this point. Then run the 
following command, which will communicate with the daemon via a unix socket and 
the daemon will realise that it needs to generate a key, triggering the bug and 
crashing:
+    $ sudo ods-enforcer zone add -z example.com -p default
+ 
+ [ Where problems could occur ]
+ 
+  * The previous code was always writing exactly 3 bytes to the buffer
+ via snprintf, so passing the full size of the buffer didn't make sense,
+ especially since the starting position was being advanced.
+ 
+  * The code is effectively generating an ascii hex string from a binary
+ data buffer.
+ 
+  * It is the responsibility of the caller to allocate a destination
+ buffer which is large enough to hold the hex string and the null byte.
+ If it does not, a buffer overflow would occur. Most invocations use the
+ stack and are fixed-sized (16 byte binary, 33 byte hex string). One
+ invocation uses the heap and is variable-sized. Due to use of
+ _FORTIFY_SOURCE=3, the fixed-sized invocations should be correctly
+ checked by the compiler. The variable sized-invocation could lead to
+ overflow in malloc()ed data. Compiler flags should help reduce the risk
+ of code execution and cause crashes instead.
+ 
+  * If the length of the input binary data is incorrect, this could lead
+ to segmentation faults, as well, if the unmapped pages are accessed.
+ 
+ [ Other Info ]
+ 
+  * I built the packages here:
+ https://launchpad.net/~lucistanescu/+archive/ubuntu/testing/

** Description changed:

- Temporary placeholder: Opening this bug in order to start the SRU
- process. Will prepare updates and testing regime first.
- 
  SRU justification:
  
  [ Impact ]
  
-  * ods-enforcerd crashes when it needs to generate a new key, thus
+  * ods-enforcerd crashes when it needs to generate a new key, thus
  rendering OpenDNSSEC installations useless.
  
-  * The issue is caused by __snprintf_chk aborting after snprintf() is
+  * The issue is caused by __snprintf_chk aborting after snprintf() is
  called with a pointer value that is beyond the start of a malloc()ed
  buffer, but with the full size of the buffer of the buffer as the second
  argument. There is no buffer overflow occurring, thus this issue only
  presents itself when the source is compiled with _FORTIFY_SOURCE=3 (from
  noble onwards).
  
-  * This is very similar to
+  * This is very similar to
  https://bugs.launchpad.net/ubuntu/+source/opendnssec/+bug/2089834, but
  in a different daemon.
  
-  * I have searched for other potential instances of _FORTIFY_SOURCE-
+  * I have searched for other potential instances of _FORTIFY_SOURCE-
  impacted functions and there were no others.
  
-  * This was fixed by upstream in
+  * This was fixed by upstream in
  
https://github.com/opendnssec/opendnssec/commit/042eaf5d7c51810ecf1d4f5c9e83d3103a6f771f
  
  [ Test Plan ]
  
-  1. Install opendnssec-enforcer and softhsm2 (the --no-insta--recommends are 
so that it doesn't unnecessarily also pull the opendnssec-signer package, but 
isn't strictly necessary):
-    $ sudo apt install --no-install-recommends opendnssec-enforcer softhsm2
+  1. Install opendnssec-enforcer and softhsm2 (the --no-insta--recommends are 
so that it doesn't unnecessarily also pull the opendnssec-signer package, but 
isn't strictly necessary):
+    $ sudo apt install --no-install-recommends opendnssec-enforcer softhsm2
  
-  2. Give opendnssec user access to softhsm2 tokens directory 
(/var/lib/softhsm/tokens/) via group membership.
-    $ sudo adduser opendnssec softhsm
+  2. Give opendnssec user access to softhsm2 tokens directory 
(/var/lib/softhsm/tokens/) via group membership.
+    $ sudo adduser opendnssec softhsm
  
-  3. Initialise a new softhsm2 token with PIN '1234' and label 'OpenDNSSEC' 
(please note that this test plan uses the package-provided configuration files 
and the PIN and label are the default values; you can choose other values, but 
these must be reflected in /etc/opendnssec/conf.xml):
-    $ sudo runuser -u opendnssec -- softhsm2-util --init-token --slot 0 
--label 'OpenDNSSEC'
+  3. Initialise a new softhsm2 token with PIN '1234' and label 'OpenDNSSEC' 
(please note that this test plan uses the package-provided configuration files 
and the PIN and label are the default values; you can choose other values, but 
these must be reflected in /etc/opendnssec/conf.xml):
+    $ sudo runuser -u opendnssec -- softhsm2-util --init-token --slot 0 
--label 'OpenDNSSEC'
  
-  4. Initialise the database (the directory is normally not writable by the 
opendnssec user, make it writable to simplify the testing):
-    $ sudo chmod 770 /var/lib/opendnssec/
-    $ sudo runuser -u opendnssec -- ods-enforcer-db-setup
+  4. Initialise the database (the directory is normally not writable by the 
opendnssec user, make it writable to simplify the testing):
+    $ sudo chmod 770 /var/lib/opendnssec/
+    $ sudo runuser -u opendnssec -- ods-enforcer-db-setup
  
-  5. In a separate terminal which should be watched, start the daemon in 
foreground mode:
-    $ sudo runuser -u opendnssec -- ods-enforcerd -d
+  5. In a separate terminal which should be watched, start the daemon in 
foreground mode:
+    $ sudo runuser -u opendnssec -- ods-enforcerd -d
  
-  6. Import the default policy configuration (this command talks to the daemon 
via a unix socket):
-    $ sudo ods-enforcer policy import
+  6. Import the default policy configuration (this command talks to the daemon 
via a unix socket):
+    $ sudo ods-enforcer policy import
  
-  7. Create a simple zone file:
-    $ sudo tee /var/lib/opendnssec/unsigned/example.com <<EOF
+  7. Create a simple zone file:
+    $ sudo tee /var/lib/opendnssec/unsigned/example.com <<EOF
  $ORIGIN example.com
  @ 3600    IN  SOA ns.example.com  admin.cnix.ro. (0 14400 3600 1209600 300)
  EOF
  
-  8. Notice that the daemon is still alive at this point. Then run the 
following command, which will communicate with the daemon via a unix socket and 
the daemon will realise that it needs to generate a key, triggering the bug and 
crashing:
-    $ sudo ods-enforcer zone add -z example.com -p default
+  8. Notice that the daemon is still alive at this point. Then run the 
following command, which will communicate with the daemon via a unix socket and 
the daemon will realise that it needs to generate a key, triggering the bug and 
crashing:
+    $ sudo ods-enforcer zone add -z example.com -p default
  
  [ Where problems could occur ]
  
-  * The previous code was always writing exactly 3 bytes to the buffer
+  * The previous code was always writing exactly 3 bytes to the buffer
  via snprintf, so passing the full size of the buffer didn't make sense,
  especially since the starting position was being advanced.
  
-  * The code is effectively generating an ascii hex string from a binary
+  * The code is effectively generating an ascii hex string from a binary
  data buffer.
  
-  * It is the responsibility of the caller to allocate a destination
+  * It is the responsibility of the caller to allocate a destination
  buffer which is large enough to hold the hex string and the null byte.
  If it does not, a buffer overflow would occur. Most invocations use the
  stack and are fixed-sized (16 byte binary, 33 byte hex string). One
  invocation uses the heap and is variable-sized. Due to use of
  _FORTIFY_SOURCE=3, the fixed-sized invocations should be correctly
  checked by the compiler. The variable sized-invocation could lead to
  overflow in malloc()ed data. Compiler flags should help reduce the risk
  of code execution and cause crashes instead.
  
-  * If the length of the input binary data is incorrect, this could lead
+  * If the length of the input binary data is incorrect, this could lead
  to segmentation faults, as well, if the unmapped pages are accessed.
  
  [ Other Info ]
  
-  * I built the packages here:
+  * I built the packages here:
  https://launchpad.net/~lucistanescu/+archive/ubuntu/testing/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2142524

Title:
  ods-enforcerd aborts on key generation in noble+

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/opendnssec/+bug/2142524/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to