Следует предположить, что уязвимость существует не только в указанном обновлении, но и во всех предыдущих обновлениях данной версии JRE. Таким образом, если предупреждение вызывает 1.8.0_151, вы должны предположить, что проблема существует в 1.8.0_ что-либо равное или меньшее-151 .
Это не ' только потому, что лучше ошибиться на стороне предостережения. Это потому, что это почти всегда фактическая реальность ситуации.
Есть несколько причин, по которым эта сводная страница CVEDetails является неполной в том смысле, что в ней не перечислены все затронутые обновления. Во-первых, Oracle изменил формат своих уведомлений CVE еще в 2014 году. Предыдущий формат был примерно таким:
, что дает понять, что уязвимость существует не только в 1.7.0_40, 1.6.0_60 и Embedded 1.7.0_40. То, что уязвимость существует в более ранних обновлениях, справедливо практически для каждой уязвимости, не только в Java, но и в любом программном обеспечении. Единственный случай, когда это не так, это когда в обновлении появилась уязвимость, и, к счастью, это довольно редко.
Oracle Более новый формат выглядит примерно так:
, которая больше не делает никаких заявлений о существовании проблема в более ранних обновлениях. Oracle вероятно сказал бы, что они делают это, потому что более ранние обновления больше не поддерживаются, и поэтому нет никакого смысла даже исследовать, уязвимы они или нет.
Фактически текущий формат Oracle делает эта позиция в явном виде:
Только уязвимые версии указаны как затронутые. Но вероятность того, что проблема существует и в более ранних обновлениях, слишком велика.
Вторая проблема заключается в том, что даже если в исходном формате оповещения указано «обновить NNN и более ранние», эта «и более ранняя» часть не отражается в CVEDetails резюме. Например, в сводке CVEDetails для JRE 1.7.0 не показано никаких уязвимостей для 1.7.0_39, 1.7.0_38, 1.7.0_37, ... даже несмотря на то, что все они были затронуты проблемой «7u40 и более ранние» в примере оригинального формат оповещения, который я показал выше.
Кроме того, какова будет ваша рекомендуемая стратегия обновления, подходящая для соответствующей безопасности JRE. Есть ли лучшие практики?
Мнения могут отличаться, и мнения о StackOverflow не совпадают c. Но IMO, всякий раз, когда выходит новое обновление (даже если оно не содержит исправлений безопасности), вы должны повторно проверить свое приложение по новой JRE, чтобы заранее знать, будут ли проблемы, когда ваши клиенты применят это обновление JRE. Если есть несовместимости, вы должны устранить их как можно скорее.
Если уязвимость серьезна и ее можно использовать в вашем приложении, то вы должны сообщить своим клиентам, что они должны применить обновление JRE, возможно, после первой установки новое обновление вашего приложения, если вы обнаружили несовместимости при повторной валидации. Если в вашем приложении слабая уязвимость и / или она не может быть использована, вы должны сообщить об этом своим клиентам, сообщить им, требует ли обновление JRE обновление приложения, и разрешить им переходить на обновленную JRE.