Jump to content

Search the Community

Showing results for tags 'security'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • FAQ
    • Project Information
  • Digital Lab Notebook (DLN) software
    • DLN Core functionality
    • Inspector tool (integrated in the DLN)
    • SIP Archiver (integrated in the DLN)
  • Capturing Data
    • Dome Method
    • Highlight Method
    • Photogrammetry
  • Processing RTI Data
    • Processing RTI Data
    • RelightLab
  • Viewing and Analyzing RTI Results
    • All Viewers
    • Dissemination
    • RTI AHRC Project (UK)
  • Regional Cultural Heritage Discussions
    • Nigerian Cultural Heritage

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 1 result

  1. Having now got to the point of being able to run DLN under Windows (with the Postgres work-around), I have observed what appears to be a highly worrying aspect – the installation of a so-called ‘private’ copy of the Java Runtime (‘JRE’) and more so the manner of that installation. This is so serious that I have just un-installed DLN from all the machines where I have been trying to install DLN, with the exception of one which I have entirely disconnected from my network and the internet and will retain as a totally-isolated machine in case I try any more DLN testing. This is nothing to do with the trustworthiness of DLN, nor is it connected with whether DLN is open-source or otherwise, and it was not an issue in the DLN Beta. The issue is that the DLN 1.0 installer installs an out-of-date un-updatable JRE which can allow malevolent actors access to compromise not only the device DLN is installed on, but potentially, say, other devices on the same network. I would absolutely support trying to maximise reliability – but that cannot be at the expense of opening loopholes which imperil not just the DLN but the platform on which it is installed and thence potentially other connected devices as well. It is important to note that these so-called ‘private’ copies aren’t really private, they are ‘personal’ copies installed for the convenience of the application, so the application knows it has a copy – but there is no barrier around those ‘private’ copies, so those copies can be executed by any other application as well. The issue arises when these programs installed for the personal use of, say, DLN, are called or manipulated by something other than DLN – be it something downloaded, or on a web page, or embedded in an email – which has malicious intent. There are different implications installing, say, ‘private’ versions of Postgres and ‘private’ versions of Java. True, there are vectors, such as SQL injection, by which malicious code can use database engines to carry out mischief, but those are (thankfully) relatively rare. Java though has major implications as it is commonly used not just for installed applications, such as DLN, but also by many many browser-based systems – and the Java Runtime (JRE) can be invoked from scripts on a web page etc. I can fully sympathise with trying to maximise reliability, and distributing applications written in Java can bring more than its fair share of these, as the Java runtime is periodically – sometimes frequently - updated to close security loopholes. Indeed, for this reason, Java may be discounted in favour of a development platform which is less vulnerable to external updates, such as those necessary to keep JRE secure. There are use cases (such as large browser-based or app-based banking systems) which use Java where each time it starts it will not only check for updates to its own programs, but also verify that the JRE is sufficiently up-to-date to be trusted; if it is not, occasionally the application will force a JRE update; more frequently it will ‘nag’ the user, or refuse to run, until the user manually updates the JRE version to a safe version. Multiple JRE versions on a device can bring both reliability issues (is my application invoking the ‘right’ JRE) and also security issues (are they all safely up to date) – and for that reason, some security policies will prohibit or block installation of what may become orphaned copies of the JRE (and in particular the jre.exe executable). It is true that, for a while at least, security patches can be issued for several major versions of Java at the same time, just like, say, for different versions of Windows. What is essential though is that updates are applied; and when a version no longer gets security updates, it is ‘retired’. (see extract below from Oracle, the JRE’s authors) JRE is labelled with major versions and also update numbers. Major versions increment usually with an increase in functionality, the minor number increments when a maintenance update is supplied to rectify bugs and/or try to close security flaws. Critical Patch Updates to the JRE are published with a minimum calendar frequency (typically every 3 or 6 months), and more frequently if urgent issues arise. Superceded (major) versions of the JRE do get updates for a while – not usually for functionality, but mainly to address faults and security vulnerabilities. The current stable JRE is now at major version 17 (with JRE 18 in beta). What is currently being installed with DLN is “JRE 11.0.11” (major version JRE 11, patch update cycle also coincidentally update 11) which was released 20 April 2021. JRE 11 was superceded by JRE 12 in, I think, 2019. Once superceded, JRE 11 would typically receive bug-fixes and security updates for a few years, JRE 11 is not yet quite end-of-life; security updates were due to end in 2023, but there has been a reprieve that security updates will be issued until 2026. This means that if security updates are kept applied JRE 11 should be able to be safely used until 2026. The current safe version of the JRE can be seen at https://javadl-esd-secure.oracle.com/update/baseline.version - for JRE 11 it is 11.0.16 – and that is irrespective of whether developers use the official Oracle Java Development Kit (JDK) or a third-party equivalent – the JRE is still the same one from Oracle, regardless of which JDK it is ‘wrapped’ in/by. Looking at the list of fixes published by Oracle for each JDK from 11.0.12 through to 11.0.16 (the current safe version), Oracle have fixed a total of 425 bugs, of which 57 were in the runtime which is used by all JDK (whether Oracle or third party). In their own support framework (JDK), in the range 11.0.12 through 11.0.16 Oracle have also fixed 43 issues in Java’s security libraries (third party dev. kit publishers may have fixed a few more or less). None of those updates are included in what DLN installs on our devices. The fault-fixes may not matter as, at worst, DLN might fail. The issue is with omission of security updates; especially as it is recognised that malevolent actors look at lists of recently fixed issues and think “I’ll try and find victims who haven’t yet updated so I can exploit that flaw and ….”. Having an old, un-patched, increasingly vulnerable version of JRE installed for DLN’s personal use may not be of that great concern, purely in terms of DLN. But, having an old, un-patched, increasingly vulnerable version of JRE is a significant loophole for the device on which it is installed, and potentially to anything else that the device with obsolete JRE is connected to as well. Whilst a proliferation of ‘personal’ copies of JRE on a device may not be ideal, it isn’t a major concern IF all of those copies are kept updated – some updates fix faults, but some close security weaknesses which have been discovered since the software is written; and many of those security issues only come to light after they start being exploited by those with ill intent. Whilst it is not good to install an out-of-date copy of the JRE, it is pretty inevitable unless the installer is refreshed frequently, but it should be OK with minimal risk if the installer then immediately either runs an update to bring whatever major version of JRE up to a safe level, or prompts the user to do so. The current DLN installer does neither – and what is far worse, it does not provide any mechanism for the user to bring JRE 11 up to a safe version either. It actually, by omitting any form of the console usually installed with Java, actually prevents the user from running any update. By effectively blocking the user from updating the JRE, that leaves responsibility for keeping the JRE at a safe level to DLN and CHI. However, I can see no facility in the DLN application, nor installed in the list of programs, nor in the installation notes, nor in the user guide. As far as I can see, this was not an issue in the DLN Beta. DM 22 July = = = = Quoting from the website of Oracle, who are the publishers/maintainers of the JRE, and who are one of the publishers of Java Development Kits (JDKs) at https://www.oracle.com/java/technologies/javase/11-0-11-relnotes.html From the release notes for JDK 11.0.11 (which includes JRE 11.0.11) which is what the DLN installer is installing (with my highlights added): “ Keeping the JDK up to Date Oracle recommends that the JDK is updated with each Critical Patch Update (CPU). In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 11.0.11) be used after the next critical patch update scheduled for July 20, 2021. “
×
×
  • Create New...