ACME certificate IDs
by Fraser Tweedale
Hi Endi,
Just want to quickly discuss certificate IDs.
Currently on ACMEBackend interface we have
public BigInteger issueCertificate(String csr);
I think this is a bit of a problem. e.g. Dogtag currently supports
multiple issuers (LWCAs). It is incidental that serial numbers do
not collide. This might not hold for other backends. Yet we need
the certificate ID to uniquely identify the certificate, so that we
can retrieve it, revoke it, etc.
I suggest changing the return value to a string (which is how it
gets stored in the ACMEOrder object anyway).
I'd further suggest that by convention, where possible, the string
be a representation of issuer+serial, which is a bit nicer for
humans looking at the stored objects than a base64url-encoded
big-endian bigint.
What do you think?
Cheers,
Fraser
4 years, 9 months
CVEs in RHEL 7
by Alex Scheel
Hey Amy,
Matt asked about our CVE response in RHEL 7.
As far as I know, we have the following CVEs (grouped below by
category).
Third Party:
- CVE-2016-10735 (bootstrap) XSS Moderate
- CVE-2018-14040 (bootstrap) XSS Moderate
- CVE-2018-14042 (bootstrap) XSS Moderate
- CVE-2019-8331 (bootstrap) XSS Moderate
- CVE-2019-11358 (js-jquery) XSS/DoS Moderate
- CVE-2015-9251 (js-jquery) XSS Moderate
These I'd recommend CLOSE->WONTFIX ; all are more work than they are worth
in the last RHEL 7 release. It requires updating our dependencies and then
re-testing the entire web UIs. They're not stored XSS and I'm not sure
there's actually a viable way to exploit these in a RHCS environment. They're
mostly about a way for a third-party site to inject content run in a trusted
execution environment on a RHCS instance. That requires substantial theme
customization (and/or changes to the server-side code to load elements from
a third-party site) to enable and is well outside the scope of our support.
Additionally, all operations are audited in our customer's deployments, so
tracking down _who_ did this would be possible. I think it is safe to close
these in RHEL 7.
I'd like to fix all of these in RHEL 8 eventually, but again, that requires
significant work and validation that we didn't break anything. All of these
third-party dependencies (Bootstrap, jquery, ...) are severely out of date,
and updating them is likely to break stuff. Doable, but not fun. :-)
First Party
- CVE-2019-10178 (TPS UI) XSS Moderate
- CVE-2019-10179 (KRA UI) XSS Moderate
- CVE-2019-10180 (TPS UI) XSS Low
- CVE-2020-1696 (TPS UI) XSS Moderate
- CVE-2020-1721 (KRA UI) XSS Low
- CVE-2019-10146 (CA UI) XSS Low
We don't have fixes for these in RHEL 8 yet. I think we should fix them in
RHEL 8 and close them in RHEL 7. Testing these is significantly easier, and
backporting would be easier. In all cases, I believe our QE team was the
reporter.
Someone familiar with this UI should probably fix them (Endi? Jack? Christina?
I'm not sure). I think the changes should probably be server-side sanitation
coupled with better front-end injection to prevent XSS. I can review, but I
wouldn't know where to start to fix them.
I wouldn't consider backporting them until someone (Amy? the customer?) is
concerned and we've fixed them.
However, my same argument about third-party ones stands here too: access is
audited so it should be easy to find out who did this.
My 2c., but I think they should be RHEL 8.3 candidates and not RHEL 7.9.
If fixes are required/requested by the customer, we can always add them in a
batch update.
Thanks,
- Alex
4 years, 9 months
