OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 26 Сентябрь, 2018 09:52

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Атаки на переполнение буфера
СообщениеДобавлено: Четверг, 14 Декабрь, 2017 13:27 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Переполнение буфера (buffer overflows) - название самой распространенной уязвимости в области безопасности программного обеспечения.
Оно стоит того, чтобы повторить, ибо требования в части недекларированных возможностей (закладок) озвучивались.
Простым примером служит следующий фрагмент программы на Си.
Код:
int namelen (void) {
    char name[21];
    gets(name);
    return strlen(name);
}

При вводе имени размером более 20 символов частью строки будет замещен адрес возврата из функции. Таким образом управление передается коду атакующего (вставленной заранее закладке) .
Виды атак:
- Атака “срыв стека”;
- Атака на указатели функций;
- Атака на таблицы переходов;
- Атака с искажением указателей данных.
Цитата:
Переполнение буфера происходит прежде всего из-за неправильного алгоритма работы программы, который не предусматривает проверок выхода за границы буферов. Также особую роль здесь играет язык программирования Си и его стандартные библиотеки. Так как Си не содержит средств контроля соответствия типов, то в переменную одного типа можно занести значение другого типа. Стандартные функции Си такие как strcpy, sprintf, gets работают со строками символов и не имеют в качестве аргументов их размеров, что, как видно из приведенных выше примеров, легко приводит к переполнению буфера. Сложившийся годами стиль программирования более ориентированный на производительность программ, без выполнения дополнительных проверок также является причиной распространения данной уязвимости.
...
Проверки выхода за границы переменной опционально реализованы в некоторых компиляторах Си, например, Compaq C, cc в Tru64 Unix, cc в Alpha Linux [14]. Следует отметить, что реализованные проверки ограничены только точными ссылками на элементы массивов, но не производятся для указателей. Существует также “заплата” для gcc, которая позволяет компилировать программы с полностью реализованной (включая проверку указателей) проверкой выхода за границы массивов [15]. Однако, у этого решения есть существенный недостаток - значительное (до 30 раз) снижение производительности программы.
...
Программистам также следует обратить свой взор на языки, обеспечивающие проверку и сохранение типов, такие как Java и Паскаль, исключающие переполнение буфера. Однако, не следует забывать, что виртуальная машина Java написана на Си и, таким образом, может иметь уязвимости.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 15 Декабрь, 2017 14:12 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Принцип as simple as possible but not simpler предполагает нахождение оптимального решения при двух мотивациях:
- мотивации упрощения (Категорический императив Калашникова: KISYBI);
- мотивации пределов допустимой наивности not simpler.
Когда человек приучен к практикам, выходящим за рамки допустимой наивности, он "совершает" (как engl. murder commit) технические решения, которые могут приводить к выходящим "за рамки" последствиям.

В критически важных отраслях:
1. Недопустимой наивностью является отсутствие объекта управления с возможностью положительных обратных связей.
2. Недопустимой наивностью является отсутствие защиты по критическому параметру, которое может привести к катастрофическим последствиям.

В киберзащищенных программных системах:
1. Недопустимой наивностью является отсутствие проверки выхода за границы массива, ибо приводит, как минимум, к уязвимости переполнения буфера.
2. Недопустимой наивностью является отсутствие проверки выхода за границы указателей на массив.
3. Недопустимой наивностью является отсутствие средств контроля соответствия типов (атака с искажением указателей данных).
4. Недопустимой наивностью является отсутствие сборщика мусора или счетчика ссылок, ибо приводит к потере целостности указателей.
В части пп.1-4 Оберон имеет необходимые средства, а вот C/C++ недопустимо наивен, и вал стандартов C++ 11,14,17 вносит гигантскую сложность, чтобы эти проблемы как-то выправить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 18 Декабрь, 2017 14:06 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Стандарты ФСТЭК только для Российской Федерации.
Международную сертификацию Common Criteria for IT Security Evaluation (CC) получают на соответствие стандартам 15408.
ГОСТ Р ИСО МЭК 15408-1
ГОСТ Р ИСО МЭК 15408-2
ГОСТ Р ИСО МЭК 15408-3


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Декабрь, 2017 18:56 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Дмитрий Дагаев писал(а):
В части пп.1-4 Оберон имеет необходимые средства, а вот C/C++ недопустимо наивен, и вал стандартов C++ 11,14,17 вносит гигантскую сложность, чтобы эти проблемы как-то выправить.

Если быть объективным, то, всё-таки, дополнительная сложность в modern C++ (а также в Rust, Eiffel, Kotlin и м.б. в некоторых других платформах, которые можно сопоставить с Оберонами в некотором смысле) возникает для решения более широкого круга задач. В плане базовых средств защиты, кроме контроля границ доступа в массивах (как и в прочих контейнерах, и в целом их поддержка как стандартных средств), контроля времени жизни объектов, соответствия типов, можем выделить (на разных платформах с различной степенью полноты):

- защита от непреднамеренной модификации объектов через указатели/ссылки. Кроме маркеров доступа к полям записей, спецификаций ссылок-аргументов функций в общем виде как "in/out/inout", все указатели, итераторы и прочие элементы, семантика которых в предоставлении косвенного доступа к другим объектам, контролируют возможность "мутабельности" целевого объекта;

- null/nil-безопасность. Различная политика ссылочных типов, указателей, допускающих nil-значение и нет. Компиляторы требуют предварительной проверки перед доступом, выявляют лишние проверки (а, к примеру, в Eiffel -- целое разнообразие политик). А также поддерживаются некоторые методики определения невалидности переменных, к примеру, после модификации контейнера данных, при которой возможна перестройка содержимого (перераспределение памяти или данных), имеющиеся "итераторы" по объекту считаются опасными (техника "регионов" и т.п. не только для встроенных средств);

- уникальные или линейные типы -- "некопируемые" объекты, с "move"-семантикой, поддержка единственной точки доступа при модификации объекта (управление дескрипторами файлов, ресурсов, разделяемыми объектами и пр., или же недопустимость доступа к одному и тому же объекту через разные переменные для правки данных, и т.п.). В т.ч. поддержка "уникальности" в функциональных типах, к примеру, если такая функция "захватывает" как замыкание внешние переменные, то захватывает их "уникально" (напр., контроль доступа со стороны параллельных или асинхронных процессов, которые должны копировать для себя данные или работать с объектами специальных типов).

Часть защит выше, скорее, как алгоритмические, в меньшей степени от внешних атак (хотя, зная конкретные проблемы алгоритма, возможно появится способ воспользоваться чем-то). И необходимо отметить, что политика платформ (для всех защит в совокупности) предполагает наиболее раннее выявление проблем, как можно больше в compiletime (и выявление лишнего функционала), минимум столкновений с фатальным "assert" в runtime.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Декабрь, 2017 20:29 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
PSV100 писал(а):
Если быть объективным, то, всё-таки, дополнительная сложность в modern C++

Я не очень понимаю, критикуете Вы меня :wink: или расширяете горизонт.

Про сложность и дырявость C++ тут говорилось предостаточно, но я акцентировал внимание на уязвимость C++ к атакам на переполнение буфера (4 вида). Современные С++ идут по пути сильного развития stl и некоторого усложнения синтаксиса. Решает ли это проблему защиты от переполнения буфера? Не решает.
- во-первых, не все пользуются этими новомодными нововведениями;
- во-вторых, эти нововведения, также имеют проблемы, о которых не все подозревают. Например, std::vector - это последовательный контейнер, инкапсулирующий массивы переменного размера. А доступ к элементам осуществляется через std::vector::operator[]. Т.е. vec[pos] на самом деле вызывает vec.operator[]( size_type pos ). И этот оператор "Возвращает ссылку на элемент по индексу pos. Проверка на выход за границы не выполняется."
Да, остается еще метод at() с проверкой, но люди по привычке или из-за оптимизации будут ляпать и ляпать.

Остальные упомянутые Вами проблемы очень интересны, только нужно их более конкретно сформулировать: Проблема ППП, язык ЯЯЯ, приводит к уязвимости УУУ, которая может быть реализована хакерской атакой ААА. Что С++ еще и в итераторах погряз так, что при модификации объекта итераторы "съезжают" - это уже и неинтересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 24 Декабрь, 2017 18:02 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Вирт говорил о кибербезопасности как ПО, так и аппаратной реализации (Reviving a computer system of 25 years ago - Wirth, 2014), отвечая на вопросы:
Цитата:
machine that is completely independent with anything, that you bought in industry, no sight tools and no backdoors nobody can plant boxing to you, and you have everything in your control

А это - трудновыполнимые требования ФСТЭК в части защиты от НСД (для краткости - только ко второму уровню контроля и только в части анализа текстов.
Цитата:
Статический анализ исходных текстов программ.
Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
- контроль полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне функциональных объектов (функций);
- синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций;
- формирование перечня маршрутов выполнения функциональных объектов (ветвей);
- анализ критических маршрутов выполнения функциональных объектов (процедур, функций) для заданных экспертом списков информационных объектов;
- построение по исходным текстам контролируемого ПО блок-схем, диаграмм и т.п., и последующий сравнительный анализ алгоритма работы функциональных объектов (процедур, функций) и алгоритма работы, приведенного в “Пояснительной записке”.

Динамический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к третьему уровню контроля, дополнительно предъявляются следующие требования:
- контроль выполнения функциональных объектов (ветвей);
- сопоставление фактических маршрутов выполнения функциональных объектов (ветвей) и маршрутов, построенных в процессе проведения статического анализа


В проекте Оберон легко можно проанализировать как аппаратное, так и программное обеспечение. Для программного обеспечения можно и блок-схему нарисовать, основной цикл Loop, и вызовы из него.

А как проводится сертификация Windows, вызывает боольшие сомнения. Это я о конкурентном преимуществе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 24 Декабрь, 2017 18:07 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
"Физприбор" объявил вторую волну конкурса для хакеров, способных взломать уникальную систему защиты.
Цитата:
"На данный момент им (участникам первой волны) не удается преодолеть наши технические решения, которые позволили бы внести изменения в технологический процесс", – сказал первый заместитель директора компании Сергей Сафонов.

Он отметил, что конкурс продлится до конца декабря. А в случае необходимости "Физприбор" готов увеличить призовой фонд.

Не взламывается простая жесткая логика...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 24 Декабрь, 2017 18:28 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
А теперь об уязвимостях 250-ти общепринятых протоколов, State of Fuzzing 2017.
Цитата:
Fuzzing is a proven technology used to find vulnerabilities in software by sending malformed input to a
target and observing the result. If the target behaves unexpectedly or crashes, then further investigation
is required. That investigation may expose a vulnerability that may be exploited for malicious purposes.

The State of Fuzzing 2017 is based on 4.8 billion test results from anonymous customers using Synopsys
Fuzz Testing (Defensics) from Jan. 1 through Dec. 31, 2016. The report provides insight into the protocols
used by different industry verticals and the relative maturity of those protocols. The relative maturity of
protocols is measured in terms of how long it takes before there is a first software failure and the overall
number of failures recorded.


Берем любые сетевые протоколы и начинает их долбить псевдослучайными последовательностями, вырабатываемыми с помощью технологии Fuzzing. Вы думаете, кто-то сможет это выдержать? Ха-ха-ха...
Цитата:
Customers tested over 250 different protocol-based suites.
The overall average time to first failure (TTFF) in 2016 was 1.4 hours.
This overall average represents a decrease from 1.7 hours in 2015 (higher number, fewer faults).
• The most mature protocol tested in 2016 was TLS Client (Core IP).
Average TTFF (average time for first failure) for TLS Client was 9 hours in 2016.
• The least mature protocol tested in 2016 was IEC-61850 MMS (ICS).
Average TTFF for IEC-61850 MMS was 6.6 seconds.

Вложение:
fuzzing.png
fuzzing.png [ 69.9 КБ | Просмотров: 1352 ]

Если у Вас хороший промышленный протокол, то Вы продержитесь "целых" 9 часов! Если плохой, но "промышленный", то 6.6 секунд. На данном уровне сложности реализации промышленных протоколов речь о неуязвимости не стоит в принципе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Декабрь, 2017 10:31 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
Дмитрий Викторович, это Вы хорошо готовитесь к летней конференции:

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Декабрь, 2017 23:37 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Федор Васильевич, это, как сказал один мой знакомый, накопление понимания. А выступить и систематизировать, конечно же, можно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Декабрь, 2017 20:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Дмитрий Дагаев писал(а):
PSV100 писал(а):
Если быть объективным, то, всё-таки, дополнительная сложность в modern C++

Я не очень понимаю, критикуете Вы меня :wink: или расширяете горизонт.

Про сложность и дырявость C++ тут говорилось предостаточно, но я акцентировал внимание на уязвимость C++ к атакам на переполнение буфера (4 вида). Современные С++ идут по пути сильного развития stl и некоторого усложнения синтаксиса. Решает ли это проблему защиты от переполнения буфера? Не решает.
- во-первых, не все пользуются этими новомодными нововведениями;
- во-вторых, эти нововведения, также имеют проблемы, о которых не все подозревают...

В С++ нет абсолютной гарантии даже при использовании Intel MPX, поскольку, как минимум, из-за исторического груза совместимости возможны всякие преобразования типов, и указатели могут "возникать" где угодно без возможности иметь метаинформацию о границах.

А исходная ремарка (выше в теме) была об ином. Критики нет, было уточнение о том, что сложность в прочих платформах возникает не только (а, может быть, не столько) из-за контроля границ, времени жизни объектов.

В вики для Cyclone -- "safe dialect of the C language" -- в рамках "language features" фактически указаны основные направления ликвидации "предельной наивности" в С, приводящей к уязвимости разного рода:
https://en.wikipedia.org/wiki/Cyclone_(programming_language)#Language_features

Презентация о ключевой технике работы с памятью в Rust -- сегодняшнее продолжение Cyclone:
http://smallcultfollowing.com/babysteps/pubs/2013.07.17-NEU.pdf

, где акцент на "регионах" (неявных и явных, заимствованных из экспериментов на ML-платформе) в совокупности с прочими семантическими принципами -- для прикидки возникающей сложности при "глобальной борьбе" за корректность (однако основная критика явных "регионов" обычно в другом контексте, который, фактически, не представлен в презентации (как и во многих других) -- в рамках структур данных, определяя "регионы" для полей данных. Кстати, в презентации отмечен некий "bug 810718: Insertion during iteration can allow a foreign website to take over your computer" -- видимо, баг был в продуктах Mozilla, с деталями не разбирался. И ессно, когда необходимо, любое API м.б. построено с проверками границ). Для сопоставления, "Null Safety", имеющаяся, напр., в Kotlin -- упрощенная, но недостаточная техника (поддержка типового набора операторов для оценки null-значения и компилятор форсирует необходимость проверок, выявляет лишние соответствующие операции), в Eiffel "Void Safety" чуть сложнее из-за политик инициализации (самоинициализации) -- в Rust (Cyclone/MLKit) осуществляется безопасность "региона" памяти -- совокупности связанных объектов.
Такова базовая безопасность в общем случае (лишь в рамках возможностей системы типизации).

И вот, если в Обероне, к примеру, ввести хотя бы семантическое разделение указателей: допускающие или нет null-значения, допускающие или нет модификацию целевого объекта -- то и в нём существенно увеличится разнообразие и сложность для типизации.

(к слову, в С++ наблюдается и концептуальная неоднозначность -- разделение "логической" и "физической" константности -- спецификатор "mutable" для полей класса, допускающий модификацию в const-методах -- теперь концепция с натяжкой согласуется с понятием уникальных (линейных) типов. И модификатор "const" весьма условный -- может быть снят при преобразовании типов данных, что в случае реальной модификации объекта приводит к "undefined behaviour", возможен и крах, если, напр., объект расположен в защищённой памяти)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Декабрь, 2017 21:44 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4106
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
А как проводится сертификация Windows, вызывает боольшие сомнения. Это я о конкурентном преимуществе.

Да никак она не проводится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Декабрь, 2017 23:28 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Борис Рюмшин писал(а):
Дмитрий Дагаев писал(а):
А как проводится сертификация Windows, вызывает боольшие сомнения. Это я о конкурентном преимуществе.

Да никак она не проводится.

А как тогда объяснить наличие позиций 291,292,293 "ОС MS Windows NT 4.0 Server, ОС MS Windows NT 4.0 Workstation" в реестре (по ссылке на 2 странице)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Декабрь, 2017 00:46 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
Дмитрий Дагаев писал(а):
Федор Васильевич, это, как сказал один мой знакомый, накопление понимания. А выступить и систематизировать, конечно же, можно.
Дак понимаем, что накопление ))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Декабрь, 2017 14:55 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4106
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
А как тогда объяснить наличие позиций 291,292,293 "ОС MS Windows NT 4.0 Server, ОС MS Windows NT 4.0 Workstation" в реестре (по ссылке на 2 странице)?


Я имел ввиду комплекс мероприятий, а не результат. Как именно он мог быть получен вопрос, полагаю, отдельных статей УК РФ...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Декабрь, 2017 18:25 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Для таких целей Microsoft предоставляет доступ к исходному коду - https://www.microsoft.com/ru-ru/securit ... ource.aspx
Цитата:
В 2002 году корпорация Microsoft разработала программу Government Security Program (GSP), в рамках которой организациям, участвующим в государственных проектах по совершенствованию защищенных информационных систем, предоставляется доступ к исходным кодам продуктов Microsoft. При этом это не означает, что Microsoft предоставляет доступ к данным пользователей.

Россия является первой страной в мире, подписавшей с Microsoft соглашение GSP — это соглашение подписано с ФГУП НТЦ «Атлас» и регулярно продлевается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Декабрь, 2017 18:54 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Я уже писал о разных способы взаимодействия за Ваши деньги. И, понятное дело, большой бизнес и, в частности, Microsoft найдет способ легального получения сертификата. Но тема не о том, а как разрабатывать ПО, соответствующее требованиям кибербезопасности.
Очевидно, блок-схему на Windows NT не нарисуешь, статический и динамический контроль все ветвления программы не проходят по-честному, и Microsoft не получится оформить
Цитата:
исходные тексты программ (ГОСТ 19.401-78), входящих в состав ПО.


За Microsoft говорить неинтересно. Интересней создавать новые простые программы, соответствующие требованиям КБ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Декабрь, 2017 19:03 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4106
Откуда: Россия, Орёл
Борис Рюмшин писал(а):
Дмитрий Дагаев писал(а):
А как тогда объяснить наличие позиций 291,292,293 "ОС MS Windows NT 4.0 Server, ОС MS Windows NT 4.0 Workstation" в реестре (по ссылке на 2 странице)?


Я имел ввиду комплекс мероприятий, а не результат. Как именно он мог быть получен вопрос, полагаю, отдельных статей УК РФ...

И так как уже у некоторых возникли ко мне вопросы, то поясню и тут: это моё оценочное суждение.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 28 Декабрь, 2017 10:36 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
О Шифровании в РФ.
Действует Указ Президента Российской Федерации от 3 апреля 1995 г. № 334.
Цитата:
Государственному таможенному комитету Российской Федерации принять меры к недопущению ввоза на территорию Российской Федерации шифровальных средств иностранного производства без лицензии

Действует Постановление Правительства РФ от 16.04.2012 N 313 (ред. от 18.05.2017)
Цитата:
К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
а) средства шифрования - аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;


Для чего я это?
1. Помним, что используя в своих программных системах средства разграничения доступа с аутентификацией (и хранением/передачей пароля), мы подпадаем под лицензированную деятельность по криптографии в стране проживания.
2. Помним, что прицепив к своим разработкам крипто-библиотеки RSA, даже хотя бы SSH с TLS, мы подпадаем под лицензированную деятельность по криптографии в стране проживания.
3. Одно неловкое движение в части разграничения доступа, - и Вы получили на свою голову кучу проблем избыточной сложности, будьте внимательны.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 22 Апрель, 2018 18:29 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2185
Откуда: Красноярск
Сходите там кто-нибудь на эту встречу OS DAY 2018 и расскажите про Оберон :)
https://scientificrussia.ru/news/v-akad ... specheniya

"Тезисы докладов и тексты статей просьба загружать до 23 апреля по ссылке:"
https://easychair.org/conferences/?conf=osday2018.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB