Доброго времени суток всем посетителям и пользователям Хабра!

Недавно я на эмоциях опубликовал статью, где я рассказывал о всех своих злоключениях при попытки создать qt приложение ( а именно вызвать и использовать

QApplication a(argc, argv);

и использовать его при помощи андроид студии. Было найдено «решение», которое было чрезвычайно костыльным. Теперь у меня были выходные, чтобы разобраться как надо работать с qt без таких костылей из андроид студии. Всем кому интересно — добро пожаловать под кат!

Так уж исторически сложилось, что в Java для свойств объектов (properties) не предусмотрено никакой физической сущности. Свойства в Java — это некоторые соглашения в именовании полей и методов доступа к ним (аксессоров). И, хотя наличие физических свойств в языке упростило бы множество кейсов (начиная от глупой генерации геттеров-сеттеров), судя по всему, в ближайшем будущем в Java ситуация не изменится.

Тем не менее, разрабатывая многослойные бизнес приложения и используя различные фреймворки для меппинга и связки (binding) данных, часто бывает необходимо передать ссылку на свойство объекта. Рассмотрим какие для этого есть варианты.

Производительность и цена – это два основных, наиболее значимых фактора в хостинге приложений. Мы часто спрашиваем себя, как тратить меньше, не ухудшая производительности приложений. В данной статье мы рассмотрим автоматическое управление памятью для Java-приложений, размещенных на облачном хостинге Infobox Jelastic с использованием сборки мусора и Jelastic GC Agent. В конце статьи небольшой сюрприз.



Для начала определим, что такое сборка мусора и что она делает для нашего Java-приложения. Затем поговорим подробнее от процессах сборки мусора в Jelastic.

По счастливой случайности мне в попала в руки консоль от двух спарков МЦСТ — R500 и R1000. Я признаюсь довольно скептически отношусь к проектам Российских электронщиков, так что мне захотелось посмотреть на их производительность. Результатами чего спешу поделиться.

Одиннадцатого декабря прошлого года вышел бюллетень Microsoft, связанный с уязвимостью, обнаруженной в Microsoft File Handling Component. Уязвимости был присвоен ранг критической и категория Remote code execution. Удаленное выполнение кода происходит при открытии жертвой общего сетевого ресурса с содержимым, сформированным злоумышленником особым образом. Подробности эксплуатации приводятся в данном отчете.

Результаты, были получены на Windows XP SP3 x86. Сама уязвимость находится в функциях FindFirstFileExW и FindNextFileExW библиотеки kernel32.dll, которые осуществляют копирование данных, полученных из нативной функции NtQueryDirectoryFile, с помощью memmove. Проблема заключается в том, что в качестве размера буфера-источника для функции копирования передается число, полученное из NtQueryDirectoryFile, хотя возможна ситуация, при которой размер буфера-приемника может быть меньше, чем результат выдачи NtQueryDirectoryFile.

Влияние данной уязвимости распространяется на все приложения, использующие функции семейства FindFirstFile/FindNextFile. Первым таким приложением, которое пришло мне в голову, было explorer.exe. Для эксплуатации злоумышленнику достаточно будет заставить пользователя открыть ссылку на зловредный ресурс, и при удачном исходе он сможет получить возможность исполнить код с правами пользователя, открывшего ссылку. Сценарий удаленной эксплуатации, как подсказывает раздел FAQ бюллетеня Microsoft, возможен через UNC share или через WebDAV-путь. Путь UNC (Universal Naming Convention) может указывать на сетевой ресурс обмена файлами, который работает на основе протокола SMB. Для теста был выбран Linux с сервисом Samba, который позволяет создавать «расшаренные» папки на основе этого протокола. В итоге хотелось смоделировать следующую схему удаленной атаки.