Изпечатай

[gat3way]

В последно време стигнах до някои потресаващи открития, за които естествено съм нямал ни най-малка идея

Например, поради ред стечения на обстоятелствата се оказва, че 64-битовият линукс е *почти* непробиваем по отношение на добре известните изтъркани buffer overflows - това включва всякакви трикове свързани със stack overflows - дори return-into-libc, всякакви безумни опити да се презаписва heap-a с глупости много трудно биха довели до отклоняване на execution flow-a и т.н.

Не съм предполагал, че нещата стоят по такъв начин....ОК, има executable flag за страници от паметта, но това го има и при PAE. Нещата обаче много брутално загрубяват по друг параграф - всички системни повиквания почват да разчитат на стойности в разни регистри, вместо в това дето е в стека. Докато преди е имало вероятност да контролираш съдържанието на стека, сега това не ти върши никаква работа. От друга страна, ELF програмите вече се зареждат по начин, по който executable pages в heap-a няма да намериш, така че да речем - препълниш динамично заделен буфер с твой си код, презапишеш някакъв адрес на callback функция да сочи натам -> програмата ще крашне.

Това ми разби фантазиите....след не много време ред видове уязвимости ще се превърнат в историческо понятие.

Разбира се има начини, но прекалено силно зависят от ситуацията и изискват....да речем гениално мислене Четох 1-2 документа по въпроса....просто е отчайващо зависещо от обстоятелствата.

Скоро ще обобщя тия глупости де

Чудно ми е обаче доколко хората биха решили да мигрират към 64-битова платформа само и само заради сигурността?

[muxozavar]

Аз лично бих мигрирал, ако всичките ми PC-та можеха да работят с 64-бит Линукс, не само заради сигурността.
Ползвам х86_64 от около година и половина на едното и всичко е ОК с дребни изключения  

[gat3way]

Днес четох още по въпроса. Което затвърждава мнението ми, че на 64-битова архитектура, атаките с препълвания на буфер са почти невъзможни.

Надеждите на хората там бяха насочени към една забавна техника. Понеже аргументите на функциите вече не се пазят *изцяло* в стека, а препълвайки стека ние можем да му контролираме съдържанието, те доразвиват return-into-libc техниката. За да може примерно да прескочат на system(), те трябва да заредят в регистрите указатели към стринга, който трябва да се изпълни. Та тяхният подход е следният:

Търсят инструкция RETQ, като ги интересува на какъв адрес се намира и какво има *преди* нея.

Примерно да речем имаме следната последователност:

<addr> pop   %rsi
<addr+1> retq

Значи презаписваме return адреса с addr. Изпълнението продължава с pop %rsi (което взема от стека 8 байта и ги предава на регистъра RSI). Значи ако *преди* презаписания return address сме сложили някаква стойност, то тя ще се предаде на този регистър. Следва retq което на своя страна взема от стека следващият return address на който да продължим...

Значи ако на края на стека имаме:

...."/bin/sh"<return_addr_2><stoinost_na_rsi - adresa na /bin/sh><addr>

където return_addr_2 е адреса на system() в паметта (примерно), а addr е адреса на онази pop %rsi инструкция, следвана от retq.

Ние можем да контролираме стойността на RSI, която се използва от system(). Ако тя сочи към адреса на "/bin/sh" в стека, значи ние можем все пак да накараме програмата-"жертва" да ни изпълни шел.

По същият начин можем да сглобим по подходящият начин нашият стек, по начин по който да предаваме стойности и на други регистри. Разбира се в по-сложни случай нещата стават като една забавна логическа задачка.


......обаче, има 2 сериозни причини дори тази магия да е практически почти невъзможна. Първата се нарича Address Space Layout Randomization, въведена е отпреди 2.6.14 някъде и гарантира различни адреси, на които да си намериш POP.... инструкцията при всяко изпълнение на програмата. Да речем че това може да се счупи с последователни опити и брутфорсване.

Втората е нещо, което редхат-ците усилено ползват и се нарича canary value. Това е една уникална стойност, която се намира в стека *преди* return адреса. Ако някъде програмата срещне RET инструкция и тази стойност не е същата, програмата крашва.

Тези две неща правят buffer overflows под x86_64 мнооооооооооого сложна задача. Не казвам невъзможна, но ужасно сложна.

Апропо, написах и първият си x86_64 shellcode, който поради гореизброените причини надали ще е особено смислен и все пак от чисто теоретичен интерес ми беше забавно

[ANTIADMIN]

Чудно ми е обаче доколко хората биха решили да мигрират към 64-битова платформа само и само заради сигурността?

До николко. Кой пуска вече такива атаки? Изключвам хората разбиващи корейски защити.
Преди да стигнеш до шела и да изпълняваш команди, не че аз ще те уча сега , има още много хляб да се яде, естествено ако администраторът не е охлюв.
Следователно, ако имаш подкаран шел, тогава няма да ти пука да направиш тази атака, тя може да се опита.
Оттук извеждам, че само заради една хипотетична buffer overflow+подобни е малко нерационално да ползваш тея тромави л****.
Каква логика ти изкарах, а?
Чета една книга за бсд и оттам такива конспирации, такива теории, че вече се чудя защо някой мисли сървър под линукс за сигурен. Малко встрани от темата, сори.
Няма ли пак някой челиндж да пускаш

[gat3way]

Като ми увре акъла и като си изградя една хубава картинка за тия неща в днешно време и под 64-битова система, ще пусна един challenge за да ви стане гадно и на вас и да минете през целия този процес на асимилиране на глупости аеххехае. Засега и аз още нямам идея - на първо време нещата изглеждат лошо от гледна точка на хахора и това не ми харесва

Кой вече пускал такива атаки....ами порче, докато има софтуер дето се пише на красиви езици като C, дотогава ще има и такива проблеми По мои груби сметки, всичките усилия, които хората хвърлят в тази насока е да направят такива атаки строго зависещи от ситуацията, изискващи повече знания, но в никакъв случаи невъзможни. Това значи да не можеш да изтеглиш експлойта от някъде и да го пуснеш ей така, но това да не означава, че бъга не може да се експлойтва. Това, което ме възмути в цялата тая работа с 64-битовите линукси е че много изведнъж летвата се вдига при това много брутално. Не че няма да му се намери цаката, но за момента просто пращат в пенсия голям брой забавни идеи.

Ако се продължава в същият дух и с липсата на качествена документация на глупостите които стават, най-накрая ще се изпълни мечтата на разни хора...за един човек навлизащ в тази тематика ще е безкрайно сложно да разбере за какво иде реч. Разни хора ще имат идея за какво става въпрос и тези хора ще са единични бройки и ще работят за целите на Империята

Та така...странно как се реве че лошите имали контрол върху личните комуникации.....ами да ама те скоро ще имат контрол и върху knowledge base-a и това ще е далеч по-страшно, защото винаги ще са с една крачка напред.

И да, препълванията на буфери и всички конспирации свързани с това със сигурност не са измишльотини и безумни фокуси, въпреки че все повече и все повече почват да се превръщат в такива.

Ще го обясня по съвсем прост начин. Утре ще хванат и ще открият някой проблем с tor. Няма да го съобщят публично, ще сканират ranges от адреси и ще преебават tor nodes. Така на теория ще могат да събират всичко дето минава през tor мрежата и никой няма да разбере за това. Всички ще си мислят, че това е криптирана onion routing простотия, но никой няма да има грам идея, че лошите събират целия трафик през нея. Забавно.

Мисля, че би било справедливо просто хората да знаят за какво става въпрос.

[ANTIADMIN]

То това е ясно. Мисълта ми беше, че при добра стратегия, дори и да влезеш някъде, може да си останеш с пръст в г*** и да се гаврят с теб, независимо колко стар софтуер имат качен или колко 0day имаш ти.
Затова е малко нерационално да кажеш - трудно е да се пускат на тази архитектура това и онова. Ами щом си стигнал дотам, да можеш да пускаш нещо, значи вече е много късно за админа, тогава архитектурата няма значение, защото buffer overflow е само една част от арсенала ти - ти си в системата и можеш да изпълняваш команди. А ако човекът е някъв нов, трудно ще се опази. Но стига съм се правил, че много разбирам, защото не го правя
Според някои хора buffer overflows няма да има в бъдеще, защото се знае, има разни тулове за сканиране на кода, това май от 20 години го потарят
да обобщя: Според мен нещата не опират до това какво можеш ти, а какво ти позволяват да можеш
За съжаление, много малко са тези хора, които позволяват, повечето май ти дават.

Сори, че разводнявам, но и без това никой не пише
/*
докато има софтуер дето се пише на красиви езици като C
*/
ми пишете си на java тогава

[gat3way]

Аз обичам красивите езици, не грозните, така че не ми говори за джава

Проблемът е че несигурното писане на код не е въпрос на разни прости patterns, така че да е лесно да се избягва. Примерно на всеки му е ясно, че не е нормално да се използва gets(), не е нормално да се използва sprintf(), strcat() и тем подобни без да се проверяват разни граници и т.н. Обаче разбира се в днешно време нещата са достатъчно сложни и въпрос на натрупване на по-прости такива. Плюс това е почти невъзможно да се проследяват heap overflows само по сорс кода например.

Buffer overflows ще има докато има езици, които го позволяват. Аналогично, всякакви проблеми с LFI/RFI/SQL injections ще ги има в езици като PHP, които го позволяват.

Аз не вярвам, че някога ще живеем в утопичен свят, където няма да има такива проблеми Винаги ще ги има. Но подходът *като_не_са_публично_известни_или_трудни_за_експлойтване_значи_не_са_проблем* не ми допада.

Както и да е, да излезем от тия малоумни размишления, така изглежда x64 shellcode-а, дето мъчих
http://www.gat3way.eu/iptablesf.txt

Оказва се все пак, че в основите си x86_64 кода има прекалено много сходство с 32-битовия x86 такъв. Всичко останало....е доста различно за жалост

[al_ned]

... лелееееее...!!!!!! А някой тук говори ли български 

[_rincewind]

бе хубаво си се загрижил за световния имериализъм:) ама да го таковам, кво значение има:)
(изключвам това че е наистина интересно, заинтригува ме и сега почвам да ровя за инфо)
но иначе, честно казано не ми дреме! тоя свят и без тва отива на бай брадър, нали сме в криза все пак. а и всеки от нас е чел поне една книжка за световната конспирация (не че няма вярно, лично аз ако имах толкоз кинти сички вие щяхте да плющите код за open source като ненормални )