Re: JEP 411, removal of finalizers, a path forward.
Hi Ron, So far we have dealt with CORBA (external library), pack200 (working on an external lib) and to support Java 17, removed some Activation class dependencies (we don't use RMID, so grabbed the missing Activation classes from Apache Harmony), thankfully these were not challenging, although replacement of some Activation classes will require downstream developers to edit their imports and recompile their code, some are still stuck on Jini 2.1 api compatibility, I have a Jini 2.1 compatibility layer, that allows them to use JGDMS without re-compiling, they will be impacted by the changes. There are a number of projects that use the Jini 2.1 api still. We have a number of our own permission implementations of course, such as DeSerialzationPermission and one that's misnamed called DownloadPermission, which should have been called "ClassLoadingPermission", because it doesn't prevent code downloads, URLPermission does that. These are actually external defenses, and are best granted to authenticated services (dynamically granted incrementally following successful authentication), these are gates in the process of loading a service proxy. We only let the good guys through the door, but we still have a gun safe to stop the kids from accidentally shooting each other. So we've figured out that we can recreate most of the authentication layer, the challenges will be implementing Java platform level guards. That's why we still need authorization controls on things like ClassLoading, network, filesystems and properties, once we allow the service proxy to load code. It appears unlikely that OpenJDK will provide hooks here, so we need to wait for finalizers to be removed, so we can instrument constructors (we don't want to inadvertently open any holes to the outside by making ClassLoader sensitive to finalizer attacks). Perhaps with ClassLoader, we should instead guard the actual methods that load classes instead of the constructor, it's not practical to do that with network connections however as it would take a big performance hit, same with filesystems. Our reimplementation of URLClassLoader is much faster because it doesn't make unnecessary DNS calls, so a small impact with guards, we may still be faster anyway. The policy tool currently used for auditing to establish trust will need to be replaced by new tools that OpenJDK is providing in future. Clearly auditing needs to increase to offset missing permission checks. Once we do that, then we can use SHA hashes to identify codebases and allow their classes to be loaded. It's still a moving target, with potentially significant implications if we get it wrong. Whether we continue developing in Java will depend on a number of factors: 1. How successful we are at navigating JEP 411. 2. Other future JEP disruptors (assuming we succeed with JEP 411). 3. Overall cost of development and maintenance in Java, v's another language. 4. Cost / benefit of using another language. 5. API stability of other languages. 6. Longevity of other languages v's Java. I'm working on the assumption that OpenJDK will close any external holes currently defended by permission checks. It would be good if the JDK was secure by default, with properties required to be set for allowing such things as agents, management, parsing xml and serialization. We still need some authorization layer controls for trusted users and services, and balance it with increased auditing of code. It's not possible with static analysis to determine the intended use of reflection, so we'll need new observability tools to replace the current policy tools. Perhaps we can link the observability tools to a service watchdog, if a service proxy misbehaves, then, it gets blacklisted and the affected JVM is immediately restarted. Our code is dynamic, so we might need to create an audit service that provides a list of audited proxy codebases and their SHA-256 hashes. Keep in mind this is all completely experimental and subject to change. Regards, Peter. On 31/07/2021 6:22 pm, Ron Pressler wrote: Hi Peter. - JEP 411, like every spec-changing JEP, is meant to allow those that use the removed functionality a migration path forward. The API elements that are deprecated for removal have some years before they are actually removed, so there’s nothing too urgent other than beginning to think of a migration path. I think it’s still too soon to consider concrete suggestions for change, especially non-trivial ones. - If by Java 8 EOL you mean the time when the last vendor offers extended support for it, then 2030 is, I believe, the *earliest* possible date that is guaranteed *now. It’s possible that support would be extended until 2130. Such offerings have no bearing on the development of current JDK versions. - The number of significant code changes required since JDK 8 to keep up with current JDK releases is, for the vast majority of
Re: Incorrect encoding of PKCS12 bag attributes
Hi Michael,
I’m not sure what exact problem you ran into, but looking at the implementation
of PKCS12KeyStore at [1] the friendly name is hardcoded to be encoded in
BMPString:
bagAttr1.putOID(PKCS9FriendlyName_OID);
DerOutputStream bagAttrContent1 = new DerOutputStream();
DerOutputStream bagAttrValue1 = new DerOutputStream();
bagAttrContent1.putBMPString(alias);
On line 2523 of the same file, it’s also always decoded as BMPString:
if (attrId.equals(PKCS9FriendlyName_OID)) {
alias = valSet[0].getBMPString();
I did try to create a PKCS12 keystore with `-alias acéü`, and the result is
indeed BMPString:
: 1E 08 00 61 00 63 00 E9 00 FC...a.c
—Max
[1]
https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L1646
> On Jul 30, 2021, at 11:26 AM, Osipov, Michael (LDA IT PLM)
> wrote:
>
> Am 2021-07-29 um 16:05 schrieb Sean Mullan:
>> Are you calling the PKCS12Attribute(String, String) constructor from your
>> code? That API currently specifies that String values are encoded as UTF-8,
>> so we could not change the behavior without a specification change. Can you
>> use the PKCS12Attribute(byte[]) constructor instead which takes a
>> DER-encoded value?
>
> Hi Sean,
>
> I don't use this API. I interact with
>> KeyStore javaTrustStore = KeyStore.getInstance("PKCS12");
>> javaTrustStore.load(null, null);
>
>> for (Rdn rdn : ldapName.getRdns()) {
>> if (rdn.getType().equalsIgnoreCase("CN"))
>> alias = (String) rdn.getValue();
>> }
>
>> javaTrustStore .setCertificateEntry(alias, cert);
>
> only. So I am using a high level API. But even if I'd use this API and pass
> the UCS-2 encoded byte array of that cert
>> CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók
>> (Certification Services),O=NetLock Kft.,L=Budapest,C=HU
>
> The ASN.1 tag would still be incorrect for friendlyName
> (1.2.840.113549.1.9.20) because it would OctetString and not BMPString.
>
> It seems to be that the API, or ObjectIdentifier and KnownOIDs classes miss
> to carry the ASN.1 tag for the actual value. Don't they?
>
> Michael
>
> PS: This CA
>> CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon
>> Merkezi,O=E-Tuğra EBG Bilişim Teknolojileri ve Hizmetleri A.Ş.,L=Ankara,C=TR
> was smart enough to stick with US-ASCII only in the CN, but still single-byte
> != two-byte UCS-2
>
>
>> On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote:
>>> Folks,
>>>
>>> can someone confirm the following bug or tell me I am too stupid to read
>>> the RFCs:
>>>
>>> I have recently created a PKCS12-based trust store and had one CA from
>>> Hungary with non-ASCII chars in the subject's CN RDN.
>>>
>>> RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
friendlyName ATTRIBUTE ::= {
WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
EQUALITY MATCHING RULE caseIgnoreMatch
SINGLE VALUE TRUE
ID pkcs-9-at-friendlyName
}
>>>
>>> So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that
>>> Java ignores the RFC and always creates an UTF8String regardless of the
>>> attribute OID, thus breaking the semantics of friendlyName.
>>>
>>> Who's wrong here?
>>>
>>> For some strange reason OpenSSL does it in a similar fashion:
>>> In pkcs12.h.in:
>>> > # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8
>>> where the function contains:
if (X509at_add1_attr_by_NID(>attrib, NID_friendlyName,
MBSTRING_UTF8, (unsigned char *)name,
namelen) != NULL)
>>>
>>>
>>> [1]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F739769c8fc4b496f08a92225a12d07414537b6c0%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fjava%2Fsecurity%2FPKCS12Attribute.java%23L230-L245data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7Cc475c3e0ca4b4dffe9e308d9529a0987%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637631643594135158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Yi0n7ZEXPHxas%2Fe17phd7ahX%2BXwlFXnCTJsYMqhLyZM%3Dreserved=0
>>>
>>>
>>> Regards,
>>>
>>> Michael
>>>
>
Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. Vladimir, David, I've (forced) pushed a smaller version of the renaming. instead of removing `sun.hotspot` classes, it copies them to `jdk.test.whitebox` (w/ `s.h.parser.DiagnosticCommand` being removed as it's used in WhiteBox signature and it was easier to update a few tests that use it), updates hotspot code to register native methods for both `sun.hotspot.WhiteBox` and `jdk.test.whitebox.WhiteBox` classes. To make it easier and not to introduce extra dependency, I've made it impossible to use `s.h.WB` w/ a security manager enabled, otherwise there would be a dependency b/w `s.h.WB` and `j.t.w.WB$WhiteBoxPermission` or there would be 2 permissions. There are no open JDK tests that are impacted by this limitation. With minor tweaks in closed source, the patch successfully passes Oracle's tier1-4. -- Igor - PR: https://git.openjdk.java.net/jdk17/pull/290
Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
> Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves > `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` > - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` > - `s/sun.hotspot.code/jdk.test.whitebox.code/g` > - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` > - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` > > testing: tier1-4 > > Thanks, > -- Igor Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 12 new commits since the last revision: - fixed ctw build - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class - updated requires.VMProps - updated TEST.ROOT - adjusted hotspot source - added test - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class - removed sun/hotspot/parser/DiagnosticCommand - deprecated sun/hotspot classes disallowed s.h.WhiteBox w/ security manager - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 - Changes: - all: https://git.openjdk.java.net/jdk17/pull/290/files - new: https://git.openjdk.java.net/jdk17/pull/290/files/8f12f2cf..237e8860 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17=290=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=290=00-01 Stats: 3248 lines in 939 files changed: 969 ins; 0 del; 2279 mod Patch: https://git.openjdk.java.net/jdk17/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk17/pull/290
Re: JEP 411, removal of finalizers, a path forward.
I'm potentially watching many years of development efforts burn, due to JEP 411 and trying to find a way to save it, I don't refer to it as fun. Frustrating, infuriating, irritating, anger, that would more accurately describe the emotions current circumstances create. I'll be focusing only on the following in Java's public API's: 1. Network. 2. File system access. 3. ClassLoading. 4. Properties. The most important task is to prevent class loading from unauthenticated sources. This is intended to sure up perimeter defenses and constrain trusted third parties in our software, these would be wide open if we just switched off SM. I'm following all guidance provided by OpenJDK in this instance. I will wait for finalizers to be removed, before instrumenting any constructors that have finalizer attack defenses. Hopefully OpenJDK will chose to remove finalizers soon, prior to removal of SM. Regards, Peter. On 31/07/2021 5:35 pm, Alan Bateman wrote: On 31/07/2021 04:04, Peter Firmstone wrote: Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? Our exchange was about instrumenting constructors that specify SM permission checks and where the classes that define these constructors have been hardened to thwart finalizer attacks. It wasn't a comment on the bigger question on how practical it is to use instrumented the entire JDK. Once you get further on then I assume a big challenge will be with APIs that separate the interface and implementation (think factory methods, APIs that define service provider interfaces ...). Here I expect you will want to instrument the implementation classes. Going deeper, you may find places where the SM check isn't on method entry but instead after defensive copying of mutable parameters or after acquiring a lock that prevents mutation while do a security sensitive operations. So non-trivial but a fun approach to explore. If you have the cycles then pick a version and try it. That will give you a sense on how much effort may be required to keep up and be confident that every interesting code path is covered. -Alan
Re: JEP 411, removal of finalizers, a path forward.
On 31/07/2021 04:04, Peter Firmstone wrote: Allan has advised when finalizers are removed, it will be practical to use Agents to instrument public API to implement an authorization layer, this is try, so can it be coordinated with JEP 411 et al? Our exchange was about instrumenting constructors that specify SM permission checks and where the classes that define these constructors have been hardened to thwart finalizer attacks. It wasn't a comment on the bigger question on how practical it is to use instrumented the entire JDK. Once you get further on then I assume a big challenge will be with APIs that separate the interface and implementation (think factory methods, APIs that define service provider interfaces ...). Here I expect you will want to instrument the implementation classes. Going deeper, you may find places where the SM check isn't on method entry but instead after defensive copying of mutable parameters or after acquiring a lock that prevents mutation while do a security sensitive operations. So non-trivial but a fun approach to explore. If you have the cycles then pick a version and try it. That will give you a sense on how much effort may be required to keep up and be confident that every interesting code path is covered. -Alan
