-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
None
-
None
**1. Do I need to fill this out?**
----------------------------------------
If you qualify for a waiver, please list the reason below and assign this sub-task to the JVT manager, who will take care of closing out assessment task and all the sub-tasks.
N/A
1.1 If this feature qualifies to skip this process, please give a brief description of why?
No.
**2. Documentation**
----------------------------
2.1 Is there a list of security requirements for this feature?
The Playground security requirements were discussed and challenged during the CSSAP process and its subsequent PenTest. Technically, the Playground is still based on those original requirements as no major changes has been introduced since its launch.
**3. Risks**
----------------
3.1 Are there any design issues that are security concerns for the dev team?
No, it is a delta security review (since https://bugs.openjdk.org/browse/JDK-8347808). This time we'd like to improve Java Playground through the feature called Fail-fast bytecode verifier here https://confluence.oraclecorp.com/confluence/display/jdr/Fail-fast+bytecode+verifier.
3.2 Are there any obvious security concerns for this feature? E.g.
- Losing crypto keys
- Exposing confidential information - data, objects, etc.
- Data integrity concerns
No. The Playground isn't handling PI and isn't persisting any data not even public data. So, there's nothing steal.
Moreover, the Playground is offered as a 'best-effort' service (no SLA).
The running cost of the Playground are extremely low thanks to its on-demand serverless design (OCI Functions, no storage, no VM). A potential DOS attack will not have any significant cost impact.
3.3 Are there any precautions needed for this feature due to data that comes from / goes to untrusted code? E.g.,
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.4 Is there a proposed change in access control of any kind? E.g.,
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.5 Has this area had any previous security issues?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.6 Any known attack patterns from previous CPUs? (JVT can assist with this point.)
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
**4. Technologies**
--------------------------
While any code could potentially fall into an infinite loop based on attacker input, there are certain technologies that pose a higher risk due to their power and/or subtlety of correct employment. To that point please note any potential use of the following technologies and please provide as much detail as exists at this time about how they are expected to be used (or indicate non-usage with "no"):
4.1 Do you expect to implement a class loader or directly use the ClassLoader API?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.2 Do you expect to use serialization?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.3 Do you implement any serializable interfaces, whether via lambda, method reference, inner class, or nonpublic class?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.4 Do you expect to use AC.doPrivileged() or other caller sensitive methods?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.5 Do you expect to make use of reflection?
- Core reflection?
- MethodHandles / 292?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.6 Do you expect to be spinning bytecode / dynamic class loading?
- 4.6a With the verifier turned off?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.7 Do you expect to use sun.misc.Unsafe?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.8 Do you expect to use other powerful sun.* classes?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.9 Do you expect to use of SQL?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.10 Do you expect to process XML from untrusted sources?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.11 Do you expect to create any processes?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.12 Do you expect to create privileged threads?
Nothing has changed since https://bugs.openjdk.org/browse/JDK-8347808
4.13 Do you expect to use any new 3rd party components?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.14 Do you expect to add native code / JNI / native libraries?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.15 Will there be any parsing of native file formats?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.16 Are any security mechanisms being added or used?
Yes. At the Java level, the snippet is sanitized before being compiled. The byte code is then instrumented to prevent any sensitive operation.
4.17 Will users need any additional permissions to use this feature?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
----------------------------------------
If you qualify for a waiver, please list the reason below and assign this sub-task to the JVT manager, who will take care of closing out assessment task and all the sub-tasks.
N/A
1.1 If this feature qualifies to skip this process, please give a brief description of why?
No.
**2. Documentation**
----------------------------
2.1 Is there a list of security requirements for this feature?
The Playground security requirements were discussed and challenged during the CSSAP process and its subsequent PenTest. Technically, the Playground is still based on those original requirements as no major changes has been introduced since its launch.
**3. Risks**
----------------
3.1 Are there any design issues that are security concerns for the dev team?
No, it is a delta security review (since https://bugs.openjdk.org/browse/JDK-8347808). This time we'd like to improve Java Playground through the feature called Fail-fast bytecode verifier here https://confluence.oraclecorp.com/confluence/display/jdr/Fail-fast+bytecode+verifier.
3.2 Are there any obvious security concerns for this feature? E.g.
- Losing crypto keys
- Exposing confidential information - data, objects, etc.
- Data integrity concerns
No. The Playground isn't handling PI and isn't persisting any data not even public data. So, there's nothing steal.
Moreover, the Playground is offered as a 'best-effort' service (no SLA).
The running cost of the Playground are extremely low thanks to its on-demand serverless design (OCI Functions, no storage, no VM). A potential DOS attack will not have any significant cost impact.
3.3 Are there any precautions needed for this feature due to data that comes from / goes to untrusted code? E.g.,
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.4 Is there a proposed change in access control of any kind? E.g.,
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.5 Has this area had any previous security issues?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
3.6 Any known attack patterns from previous CPUs? (JVT can assist with this point.)
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
**4. Technologies**
--------------------------
While any code could potentially fall into an infinite loop based on attacker input, there are certain technologies that pose a higher risk due to their power and/or subtlety of correct employment. To that point please note any potential use of the following technologies and please provide as much detail as exists at this time about how they are expected to be used (or indicate non-usage with "no"):
4.1 Do you expect to implement a class loader or directly use the ClassLoader API?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.2 Do you expect to use serialization?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.3 Do you implement any serializable interfaces, whether via lambda, method reference, inner class, or nonpublic class?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.4 Do you expect to use AC.doPrivileged() or other caller sensitive methods?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.5 Do you expect to make use of reflection?
- Core reflection?
- MethodHandles / 292?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.6 Do you expect to be spinning bytecode / dynamic class loading?
- 4.6a With the verifier turned off?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.7 Do you expect to use sun.misc.Unsafe?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.8 Do you expect to use other powerful sun.* classes?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.9 Do you expect to use of SQL?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.10 Do you expect to process XML from untrusted sources?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.11 Do you expect to create any processes?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.12 Do you expect to create privileged threads?
Nothing has changed since https://bugs.openjdk.org/browse/JDK-8347808
4.13 Do you expect to use any new 3rd party components?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.14 Do you expect to add native code / JNI / native libraries?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.15 Will there be any parsing of native file formats?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808
4.16 Are any security mechanisms being added or used?
Yes. At the Java level, the snippet is sanitized before being compiled. The byte code is then instrumented to prevent any sensitive operation.
4.17 Will users need any additional permissions to use this feature?
No. Nothing changed since https://bugs.openjdk.org/browse/JDK-8347808