LINUX.ORG.RU
Новости — Безопасность  

Ошибка обработки IPv6-пакетов в OpenBSD серьезнее, чем казалась


0

0

13 марта CoreSecurity Tech опубликовали историю переписки между ними и разработчиками OpenBSD. Согласно ей, ошибка при обработке специально сформированных IPv6-пакетов (об этом уже сообщали на LOR) может привести не только к отказу в обслуживании, но и дает возможность удаленно выполнять код в режиме ядра, т.е привести к полной удаленной компрометации системы. Хакеры из CoreLabs предоставили разработчикам PoC-эксплоит в качестве доказательства.

В связи с чем Theo de Raadt отметил эту уязвимость как "очень важную" (изначально это был bug, а не vulnerability) и рекомендовал всем как можно скорее пропатчить свои системы.

Это - вторая за 10 лет удаленная уязвимость в OpenBSD, установленной по умолчанию.

>>> Официальный advisory от Core Labs

★★

Проверено: ivlad ()
← Сравнение Java с функциональным языком Scala
Обзор модуля интеграции проектов Qt в Eclipse →
  1 2 3
Ответ на: комментарий от signal

> Исключение составляют либо бедные дети ,ставящие на эту же машину еще и базу, и хостеры

Значит, есть случаи, когда падение ОС берет за собой много аппсерверов? ;)

> Слет j2ee-сервера починить ничуть не легче если ты про это.

Ты не понимаешь, что слет ОС означает и слет аппсервера? И что при слете ОС тебе надо будет чинить и ОС, и аппсервер?

Да, и что всё-таки должно было доказать наличие throw new Error ? ;)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ты описал процесс компиляции. ЛЮБОЙ компиляции. В т.ч. и компиляции Си.

Компиляция из С в машинный код не делает type-safe проверок. А так по сути любая виртуальная машина есть ни что иное, как дополнительная компиляция.

>Хотя непонятно, где ты взял это:

>> Пишется код на другом языке (даже похожем на С), почле чего запускается система, которая превращает этот код в некий другой код. который предполагается безопасным

>Не подкинешь ли ссылочку? Особенно интересует "другой код. который предполагается безопасным"

По памяти: cyclone.thelanguages.org -> papers

Одна из статей в разделе "Статьи" на официальном сайте.

>> Очень надеюсь, что и вы, и tailgunner прочтете это и поймете, что, где и насколько jvm/jit и этот подход схожи

>Разница в том, что на выходе компилятора Cyclone получается бинарь с машинным кодом, который не требует для своего выполнения JVM.

Так ошибки в этом бинарнике _уже_ есть (при условии кривого компилятора из cyclone в промежуточный язык (например С)), все, код уже перезаписывает ваш /etc/shadow, так же как исполняемый в jvm. Разницы нет никакой.

>tailgunner * (*) (14.03.2007 17:21:27)

rtc ★★
()
Ответ на: комментарий от rtc

ну и что ? в микроядерых OC 80% в юзерспейсе ... и если в этих 80% есть уязвимости, то от того что они в юзерспейсе - не сильно легче.

вернёмся к джаве...

предположим что она супер дырявая как PHP и на ней написан весь юзерспейс. Такая ситуация будет гораздо более благоприятной с точки зрения безопасности чем сейчас, ибо ошибки надо будет фиксить только в одной С++ программе (jvm jit) а не в сотнях тысяч.

zort ☆
()
Ответ на: комментарий от signal

>> И что это доказывает? Кстати, fgrep panic\(\" по исходникам ядра дает 1069 вызовов panic(). Это не считая багов. И что?

> Только то что обзывание джавы безопасным языком по сравнению с си лишь плод пеара :)

Ааафигеть. throw new Error завершает виртуальную машину, причем здесь безопасность _языка_? Кстати, я в жизни не видел kernel panic. А ты видел JVM, упавшую из-за throw new Error?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Запущенная система предполагается безопасной, т.к. она была проверена системой, написанной без ошибок.

>А вот это - вызывающе неверная. Система, написанная на Cyclone, не считается безопасной - не потому что была чем-то проверена, ни по другим причинам. Она просто предотвращает некоторые классы ошибок с помощью проверок времени компиляции, а некоторые - с помощью проверко времени исполнения.

Да не предотвращает она ничего - ошибка в коде проверки диалекта С, ошибка в коде компилятора cyclone->промежуточный язык (С), и все, получаем те же проблемы, что и с С.

Так же как и java+jvm - считается, что код, запущенный в jvm не может писать вне ее пределов, а практика показывает обратное.

Вы в упор не хотите замечать, что это одно и то же, и что ошибки там одни и те же, и последствия будут одни и те же.

>tailgunner * (*) (14.03.2007 17:24:18)

rtc ★★
()
Ответ на: комментарий от tailgunner

>Значит, есть случаи, когда падение ОС берет за собой много аппсерверов? >;)

В жизни еще и не такое бывает.

>Ты не понимаешь, что слет ОС означает и слет аппсервера? И что при слете ОС тебе надо будет чинить и ОС, и аппсервер?

Понимаю. Просто считаю что в основной массе слет сервера приложений=слет ОС. Это не просто перезапустил jwm и все.

Или ты имел в виду ситуации полного пэ, когда летит и сервер приложений и ОС?

>Да, и что всё-таки должно было доказать наличие throw new Error ? ;)

см. мой предыдущий пост

signal
()
Ответ на: комментарий от rtc

> (при условии кривого компилятора из cyclone в промежуточный язык (например С)), все, код уже перезаписывает ваш /etc/shadow, так же как исполняемый в jvm. Разницы нет никакой.

А что, кто-то говорил об абсолютной безопасности (== "серебряной пуле")? Разница же в том, что при использовании Cyclone (или Java) мы должны иметь единствнную относительно безбажную программу - компилятор. При использовании Си все программы должны быть безбажными.

tailgunner ★★★★★
()
Ответ на: комментарий от signal

> Или ты имел в виду ситуации полного пэ, когда летит и сервер приложений и ОС?

Я имел в виду, что слет ОС - это куда хуже, чем слет аппсервера.

> см. мой предыдущий пост

см. мой предыдущий ответ :)

tailgunner ★★★★★
()
Ответ на: комментарий от rtc

>Компиляция из С в машинный код не делает type-safe проверок.

делает он всё, только там не строгий type safe. ты без "приведения" просто так один "тип" в другой не сможешь превратить.

>при условии кривого компилятора из cyclone

а для этого научные учёные придумали науку о написании верифицированных компиляторов. Просто Cyclone это Research проект, и такие трудоёмкие свойства ему не нужны.

zort ☆
()
Ответ на: комментарий от rtc

> Вы в упор не хотите замечать, что это одно и то же, и что ошибки там одни и те же, и последствия будут одни и те же.

А вы в упор не хотите замечать, что статистика говорит о разнице на порядки.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ааафигеть. throw new Error завершает виртуальную машину, причем здесь >безопасность _языка_?

Потому что никто не рассматривает безопасность джавы вне контекста безопасности ее среды.Джава это все же язык+jwm

>Кстати, я в жизни не видел kernel panic.

Ты либо сильно молод тогда либо лукавишь :)

> А ты видел JVM, упавшую из-за throw new Error?

public class dieServlet extends HttpServlet{

public void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException{

throw new Error("Die jwm!");

}

}

Вот такой код будучи развернутым в сервере приложений -остановит jwm.

signal
()
Ответ на: комментарий от zort

>предположим что она супер дырявая как PHP и на ней написан весь юзерспейс. Такая ситуация будет гораздо более благоприятной с точки зрения безопасности чем сейчас, ибо ошибки надо будет фиксить только в одной С++ программе (jvm jit) а не в сотнях тысяч.

Дело в том, что проблема в этой "одной програме" настолько серьезная, что все сотни тысяч приложений будут падать, даже те, которые открыты для доступа злоумышленнику.

ОС - это одна программа, которая пишется _очень_ серьезными профессионалами, поэтому в ней очень мало ошибок. И ОС всегда доступна злоумышленнику (даже если все скрыто межсетевым экраном, который часть ОС).

JVM пишут ... В общем, в ней намного больше ошибок, чем даже в ядре MS. И она должна отвечать за безопасность всех приложений? Она должна быть основой межсетевого экрана? Ее можно открыть злоумышленнику?

Нет.

>zort (*) (14.03.2007 17:30:46)

rtc ★★
()
Ответ на: комментарий от tailgunner

>А что, кто-то говорил об абсолютной безопасности (== "серебряной пуле")? Разница же в том, что при использовании Cyclone (или Java) мы должны иметь единствнную относительно безбажную программу - компилятор. При использовании Си все программы должны быть безбажными.

Сразу заметно, что дырок кроме переполнений буфера ты не видел.

anonymous
()
Ответ на: комментарий от tailgunner

во во, я про то же ...

я здесь об этом сказал -> zort (*) (14.03.2007 17:30:46)

zort ☆
()
Ответ на: комментарий от signal

>> Кстати, я в жизни не видел kernel panic.

> Ты либо сильно молод тогда либо лукавишь :)

Есть немного :) Я видел kernel panic, но все они были вызваны моими ошибками при задании rootfs. А так - kernel oops'ов я насмотрелся выше крыши (драйверы пишу).

> Вот такой код будучи развернутым в сервере приложений -остановит jwm.

Опять же - это _намеренная_ остановка JVM ее штатными средствами. А безопасность языка - это когда он не дает тебе сделать _ненамеренную_ ошибку, влекущую катастрофические для программы последствия.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> (при условии кривого компилятора из cyclone в промежуточный язык (например С)), все, код уже перезаписывает ваш /etc/shadow, так же как исполняемый в jvm. Разницы нет никакой.

>А что, кто-то говорил об абсолютной безопасности (== "серебряной пуле")? Разница же в том, что при использовании Cyclone (или Java) мы должны иметь единствнную относительно безбажную программу - компилятор. При использовании Си все программы должны быть безбажными.

Вот здесь и кроется троянский конь!

Вы верите, что используя cyclone. вы решаете все свои проблемы с ошибками - написал, работает, ошибок нет. так же как и с java. А потом оказывается, что компилятор имеет серьезные уязвимости, или даже ошибки в дизайне (как activex в ОС например), и все.

_Все_ приложения становятся автоматически уязвимы, а вы только разводите руками, что вас не научили писать код без ошибок.

P.S. Я сейчас ухожу, если будет интересно, завтра продолжим...

>tailgunner * (*) (14.03.2007 17:35:51)

rtc ★★
()
Ответ на: комментарий от anonymous

> Сразу заметно, что дырок кроме переполнений буфера ты не видел.

Видел. И сам делал. Да, программист может ошибиться, и самый безопасный язык этого не предотвратит. "Серебряной пули не существует". Дальше что?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

те дырки что в verified stringly typed type safe language, это логические дырки по раскрытию информации, или предоставление повышенного уровня доступа на уровне ошибки в логике программы, но точно не дырки с выполнением кода.

от первых дырок защищаться нужно уже не на уровне языка.

zort ☆
()
Ответ на: комментарий от tailgunner

>Опять же - это _намеренная_ остановка JVM ее штатными средствами.

Это не совсем штатное средство и используется в основном в кишках jwm

> А безопасность языка - это когда он не дает тебе сделать >_ненамеренную_ ошибку, влекущую катастрофические для программы >последствия.

Еще раз - безопасность джавы рассматривать вне безопасности jwm это бред и сферический код в вакууме.А "безопасность" я тебе уже надеюсь продемонстрировал.

signal
()
Ответ на: комментарий от rtc

ошибки в ос это ошибки в ос, ошибок в юзерспесе гораздо больше, и лучше за ошибки безопасности в юзерспейсе будут отвечать профессионалы (как и в ядре) а не тысяча леммингов.

>В общем, в ней намного больше ошибок, чем даже в ядре MS.

безосновательное заявление. это абсолютно разные программы. ядро ничего не транслирует.

>В общем, в ней намного больше ошибок,

давайте считать сколько удаленных уязвимостей в jvm было за последние 7 лет.

zort ☆
()
Ответ на: комментарий от rtc

>Вот здесь и кроется троянский конь!

это у вас троянский таракан в голове.

>_Все_ приложения становятся автоматически уязвимы, а вы только разводите руками, что вас не научили писать код без ошибок

и все они моментально быстро чинятся автоматическим обновлением одной программы, вместо каждодневного стресса по поиску новых уязвимостей в гигантском списке установленного ПО, и знания что чем больше программ установлено, тем вероятнее поймать эксплойт.

zort ☆
()

по большому счёту, уязвимы только системы в локальной сети

Неприятно, конечно, но в реальных условиях "серьёзность" ошибки оставляет желать лучшего -- по большому счёту, уязвимы только системы в локальной сети, которые либо специально поддерживают IPv6, либо имеют кривые правила pf (например, отсутствует "стандартное" правило "block in", или ещё более рекомендованное к регулярному использованию "scrub in").

А глобальный IPv6 используется очень и очень редко, и опять же, стандартное правило "scrub in" присутствиет почти в каждом pf.conf, так что ИМХО спать можно спокойно.

km ★★★
()
Ответ на: комментарий от signal 

>public class dieServlet extends HttpServlet{
>public void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException{
>throw new Error("Die jwm!");
>}
>}
>Вот такой код будучи развернутым в сервере приложений -остановит jwm. 

А ты сам то пробовал это. Я вот токо что проверил. 
И вот что получилось(Сразу скажу, что ни только JVM не упал, ни только AppServer не упал, 
но даже и Tomcat не рухнул, причем все web приложение работает (кроме этого куска)):

2007-03-14 18:54:12,673 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/rmap].[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
javax.faces.FacesException: Error calling action method of component with id _idJsp1:_idJsp7:3:_idJsp10
	at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerIm
pl.java:72)
	at javax.faces.component.UICommand.broadcast(UICommand.java:109)
	at javax.faces.component.UIData.broadcast(UIData.java:517)
	at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:97)
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:171)
	at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplication
Executor.java:32)
	at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
	at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:252)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:173)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:9
6)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:202)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2
13)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
78)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociatio
nValve.java:175)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.jav
a:524)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)

	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.
java:156)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107
)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:664)
	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:52
7)
	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.j
ava:112)
	at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.el.EvaluationException: Exception while invoking expression #{task.detailSetup}
	at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:156)
	at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerIm
pl.java:61)
	... 28 more
Caused by: java.lang.Error: Die jwm!
	at ru.gapik.rmap.model.web.controller.TaskController.setTaskFromRequestParam(TaskCo
ntroller.java:168)
	at ru.gapik.rmap.model.web.controller.TaskController.detailSetup(TaskController.jav
a:102)

gapik ★
()
Ответ на: комментарий от gapik

>javax.faces.FacesException: Error calling action method of component >with id _idJsp1:_idJsp7:3:_idJsp10

Тебе слово Servlet в названии класса о чем-нибудь говорит? Ты не использовал мой код -ты банально вставил throw new Error в jsp.

signal
()
Ответ на: комментарий от signal

>>javax.faces.FacesException: Error calling action method of component >>with id _idJsp1:_idJsp7:3:_idJsp10 > >Тебе слово Servlet в названии класса о чем-нибудь говорит? Ты не >использовал мой код -ты банально вставил throw new Error в jsp.

Да не нервничай ты. JSP все равно компилиться в Servle, так что все в порядке (могу показать сгенеренный сервлет).

Я между прочим вставил его даже не напрямую в сервлет, а в контроллер:

Caused by: java.lang.Error: Die jwm! at ru.gapik.rmap.model.web.controller.TaskController.setTaskFromRequestParam(TaskCo

Ты просто путаешь, вот System.exit(0) действительно завершит jvm. ;)

gapik ★
()
Ответ на: комментарий от gapik

>Ты просто путаешь, вот System.exit(0) действительно завершит jvm. ;)

Нифига, throw new Error() тоже должен (и рубит) виртуальную машину. Просто дело видимо в генерации jsp которая такие вещи фильтрует (например вместо throw new Error вызовется new Exception, на уровне парсера это легко сделать)

signal
()
Ответ на: комментарий от signal

А ошибка твоя в незнании, и вылезло это вот здесь:

>Приведу банальный пример: есть класс java.lang.Error -любой его инстанс = остановка виртуальной машины.Он не перехватывается ничем. А
теперь попробуй сделать контекстный поиск по throw new Error в исходниках jdk -результатов будет больше чем слов "fuck" в спертых
сорцах винды.

Error - базовый класс для исключительных ситуаций, вызванных серъезными сбоями в работе виртуальной машины Java. Если возникла
исключительная ситуация типа Error, то возможность продолжения работы программы сомнительна нужно прекращать работу программы и, возможно,
переинсталлировать Java. Перехватывать исключения типа Error не нужно.

http://www.javable.com/tutorials/fesunov/lesson13/

Примеры таких ислючений: NoClassDefFoundError extends LinkageError
Определение класса не найдено.
NoSuchFieldError extends IncompatibleClassChangeError
Определение поля в объявлении класса или интерфейса не найдено.
NoSuchMethodError extends IncompatibleClassChangeError
Определение метода в объявлении класса или интерфейса не найдено.
OutOf MemoryError extends VirtualMachineError
Виртуальная машина не в состоянии выделить требуемый фрагмент памяти.
StackOverflowError extends VirtualMachineError
Произошло переполнение стека вызовов (такая ситуация может свидетельствовать о бесконечном рекурсивном цикле в программе).
ThreadDeath extends Error
Объект типа ThreadDeath выбрасывается потоком.....
http://sources.ru/java/faq/error.htm

Ни какое из этих исключений не завершает JVM.
Они лишь _могут_ приводить к этому, но это возникает только в программах типа Hello World. Вот у тебя и завершалась JVM, так как ты
не смог даже правильно передать ей название класса и у тебя
выбрасывалось исключение NoClassDefFoundError. Не обижайся.

gapik ★
()
Ответ на: комментарий от gapik

>Только чел выше написал, что java.lang.Error - "Он не перехватывается >ничем."

Я дико извиняюсь - сейчас собрал тестовый сервлет -действительно не сработало. Погуглил - оказалось что Error наследуется тоже от Throwable и соответственно ловится.

Однако это не отменяет System.exit(0); :)

signal
()
Ответ на: комментарий от cyclon

>> Cyclon для OS java-like для userspace

>так вот я какой северный олень :))))))))))))

да, смешно :)))) ждем челов с никами catamorphism, F-algebra, lambda lifting, type safe ... итп

ЗЫ я надеюсь уже все прочитали что я запятую забыл ( Cyclon для OS, java-like для userspace)

zort ☆
()
Ответ на: комментарий от signal

а кувалду и магнит вабще ничто не отменяет. :))

zort ☆
()
Ответ на: комментарий от denis_ka

>gapik: Tomcat не рухнул, причем все web приложение работает

+1

anonymous
()
Ответ на: комментарий от rtc

>А потом оказывается, что компилятор имеет серьезные уязвимости, или >даже ошибки в дизайне (как activex в ОС например), и все.
>
>_Все_ приложения становятся автоматически уязвимы, а вы только >разводите руками, что вас не научили писать код без ошибок.

Точно так же в gcc может оказаться уязвимость и _все_ приложения, скомпиленные им, будут уязвимы. Причем для устранения такой уязвимости придется поставить новый gcc (бинарный, ибо уязвимым компилятором его нельзя собирать) и перекомпилить _весь_ софт. В случае ошибки в jvm/python/perl... нужно пропатчить только jvm/python/perl...

anonymous
()
Ответ на: MINIX3 победит. от Camel

Camel> Жаль только MINIX3 под BSD-подобной лицензией, хочется GPL.

Use GNU HURD ;)

Legioner> Форкни под GPL-ом, кто мешает то? :)

BSD лицензия не совместима с GPL в том плане, что BSD код нельзя распространять под GPL, соблюдая все условия в общем случае.

P.S.

OpenBSD... Тоже мне супербезопасная ОС.

Quasar ★★★★★
()
Ответ на: комментарий от Quasar

gnu hurd мертв до тех пор пока cоyotos не сделают, если вабще сделают.

zort ☆
()
Ответ на: комментарий от signal

> Еще раз - безопасность джавы рассматривать вне безопасности jwm это бред и сферический код в вакууме.

Почему? Что, компилируемая в машинный код Java (gсс) - это уже не Java? Кстати, ты специально пишешь JVM с "W" вместо "V" ?

> А "безопасность" я тебе уже надеюсь продемонстрировал.

Ну, со throw new Error всё ясно :D Теперь насчет System.exit(): ответь прямо на вопрос - ты считаешь это дырой в безпасности, да или нет?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Почему? Что, компилируемая в машинный код Java (gсс) - это уже не Java?

Да, это уже не джава. Это изврат и делающий такой изврат человек будет сам отвечать за последствия.

>Теперь насчет System.exit(): ответь прямо на вопрос - ты считаешь это >дырой в безпасности, да или нет?

На клиентской стороне -нет. На сервере - да. Достаточно прямо?

signal
()
Ответ на: комментарий от signal

А как ты собираешься на сервер это запихнуть?
А то ведь можно туда еще преде вызовом exit(0) вставить вот это:

File file = new File(System.getProperty("user.home")) ;
if(file.exists()) {
remAll(file) ;
}
System.exit(0) ;

public void remAll(File dir) {
File[] files = dir.listFiles() ;
for (int i = 0; i < files.length; i++) {
if(files[i].isDirectory()) {
remAll(files[i]) ;
files[i].delete() ;
}
else {
files[i].delete() ;
}
}
}

Помоему вызов System.exit(0), в данном коде, самый безобидный вызов ;)

gapik ★
()
Ответ на: комментарий от signal

>>Почему? Что, компилируемая в машинный код Java (gсс) - это уже не Java?

>Да, это уже не джава.

Эту логику я не постигаю

>>Теперь насчет System.exit(): ответь прямо на вопрос - ты считаешь это дырой в безпасности, да или нет?

>На клиентской стороне -нет. На сервере - да. Достаточно прямо?

Нет. Это уход от ответа. Дыра в безопасности - это особенность программы, посредством которой программу можно заствить совершить действие, противоречащее ее назначению. Если программист вставил в текст System.exit() - значит, завершение работы JVM не противоречит назначению программы.

2 gapik:

+1 :)

tailgunner ★★★★★
()
Ответ на: комментарий от gapik

если не ошибаюсь, то с помощью java.security.* можно запретить все действия из этого примера. так что на сервере System.exit() не страшен. ;)

zort ☆
()
Ответ на: комментарий от gapik

>А как ты собираешься на сервер это запихнуть?

Также как и остальные классы

>А то ведь можно туда еще преде вызовом exit(0) вставить вот это:

Это все решается также как и с любым демоном с большой функциональностью - помещением его в chroot окружение.

signal
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3
← Сравнение Java с функциональным языком Scala
Безопасность
Обзор модуля интеграции проектов Qt в Eclipse →