Компания Sun Microsystems выпустила внеплановые версии обновления Java:
JRE 6 Update 13 (http://java.sun.com/javase/6/webnotes/6u13.html),
JRE 5.0 Update 18 (http://java.sun.com/javase/downloads/index_jdk5.jsp), JRE 1.4.2_20 (http://www.sun.com/software/javaseforbusiness/getit_download...) и JRE 1.3.1_25 (http://java.sun.com/j2se/1.3/download.html) с исправлением 16 уязвимостей (http://secunia.com/advisories/34451/), уровень опасности 9 из которых оценивается как критический:
- Ошибка в JRE LDAP клиенте может быть использована злоумышленником для загрузки и выполнения произвольного кода, при получении специально подготовленных данных со стороннего LDAP сервера;- Переполнение буфера и целочисленное переполнение в JRE, позволяют двумя разными способами выполнить код злоумышленника в момент распаковки средствами утилиты "unpack200" специально модифицированных JAR архивов, с апплетами и приложениями Java Web Start;
- Ошибка распаковки сериализированных данных в Java ...
URL: http://java.sun.com/javase/6/webnotes/6u13.html
Новость: http://www.opennet.me/opennews/art.shtml?num=20948
Жаль только в убунтовских репах её не будет до октября :(
обновления безопасности все равно выпустят даже для выпущенного релиза. в чем паника?
Дать подать сюда этих тяпкиных-ляпкиных^W жавофилов оравших что веб-приложения через яву - якобы безопасно.Глядя на такой changelog я уж лучше без ява-приложений в браузере как-нить обойдусь.
unpack200 написан на C или на C++.
Внешний LDAP-сервер — скорее всего тоже.
"Обработчики" GIF и PNG — 100% неуправляемый код на C, вызываемый из Java-приложений.Так кто от кого защищается?
>"Обработчики" GIF и PNG — 100% неуправляемый код на C, вызываемый из Java-приложений.Правильно, потому что если написать это на яве - юзер от тормозов повесится нахрен.
> Так кто от кого защищается?
От вот этой вот "якобы безопасной" технологии.Не выполнять java-stuff с веб страниц - наиболее безопасно ИМХО.Тогда никто не переполнит буфера лишний раз, не обойдет в стопервый раз ограничения JVM и прочая.Понимаю бы если б это было единоразово, но оно ж постоянно вот так вот.Как-то changelog не внушает оптимизма, дыра на дыре и дырой погоняет.
Ну тогда, для начала, я бы рекомендовал вам отказаться от JavaScript: думаю, что он поопасней будет.
>>"Обработчики" GIF и PNG — 100% неуправляемый код на C, вызываемый из Java-приложений.
>Правильно, потому что если написать это на яве - юзер от тормозов повесится нахрен.Нет. Это потому, что лесяпед никому не хочется изобретать — LZMA и ZIP уже написаны на C и код довольно большой для полного перевода его на Java. Легче использовать то, что есть, и по идеологическим причинам — "побочные эффекты" должны быть одни, а не много и разных.
>От вот этой вот "якобы безопасной" технологии.Не выполнять java-stuff с веб страниц - наиболее безопасно ИМХО.Тогда никто не переполнит буфера лишний раз, не обойдет в стопервый раз ограничения JVM и прочая.Понимаю бы если б это было единоразово, но оно ж постоянно вот так вот.Как-то changelog не внушает оптимизма, дыра на дыре и дырой погоняет.
Посмотрите, с каким упорством чинятся дыры в Firefox и (не)чинятся в IE. Чуть ли не каждые две-три недели выходят новые минорные версии и заплатки, соответственно!
опять всё с ног на голову.
причину то я понять могу - да не хочется.. уже написано... на этом страшном и ни кем не управляемом С...но когда в рекламных роликах говорят о жабе, то не упоминают, что она использует этот страшный С.
возникает вопрос. а что ещё страшного она использует?
p.s.
здесь можно заменить слово жаба на любое другое... впрочем как и С... и даже поменять их местами. дырки есть и точка... в законченном и объявленном безопасным (а иногда и самом безопасным) ПО.
> Так кто от кого защищается?В том то и дело. Чтобы действительно получить от управляемого кода преимущество в безопасности, все пользовательское пространство полностью должно быть в управляемом коде. Думаю, что OS следующего поколения будут устроены именно так. Уже есть JNode, Inferno, Singularity.
Oberon и Bluebottle ;-) http://bluebottle.ethz.ch/
Oberon постарше Java будет.
Жаль, что в Java байткод стали сразу использовать не подумав.
В .NET подход более правильный, хотя тоже идея Витра как и байткод.
> В .NET подход более правильныйЧем именно? На самом деле интересно, поскольку я преимуществ .NET перед Java не вижу.
>> В .NET подход более правильный
>
>Чем именно? На самом деле интересно, поскольку я преимуществ .NET перед Java
>не вижу.В .Net используется AOT (Ahead Of Time compiler) — приложение при первом запуске ГРУБО компилируется в бинарник, понятный операционной системе, после запуска .exe окончательно JIT'ится и кладётся в кэш (GAC) — ну точно локальный репозиторий. :)
А преимществ .Net перед Java нет, так как это несопоставимые программные технологии.
> В .Net используется AOT (Ahead Of Time compiler)Для Java есть GCJ, плюс никто не мешает добавить в Java механизм AOT компиляции аналогичный тому, который в .NET - это вопрос частной реализации, а не технологии в целом.
> А преимществ .Net перед Java нет, так как это несопоставимые программные технологии.
Разве? Проблема только в том, что под словом Java очень много всего сразу подразумевается, .NET - тоже много всего. Можно сравнивать JVM и CLR, язык Java и C#, FCL и Java API.
Хорошо, на чём вы предлагаете писать веб-приложения?
>Хорошо, на чём вы предлагаете писать веб-приложения?На JRuby. Нет? :)
А Groovy ?
>А Groovy ?медленный газ
grails медленнее чистого spring mvc всего на четверть...
>grails медленнее чистого spring mvc всего на четверть...Grails == замена ПХП, но никак не клиентского rich-приложения типа Web-браузера.