Български политически животни

Post Syndicated from Емилия Милчева original https://www.toest.bg/bulgarski-politicheski-zhivotni/

Български политически животни

На Аристотел принадлежи определението, че „човекът е политическо животно по природа“, тъй като може да достигне своя най-висок потенциал, като се занимава с нещата, касаещи полиса – тоест с политика. Колко висок е потенциалът на българските политически животни, повели обществото към шести парламентарни избори за последните три години?

Тестът за шестата поправка на Конституцията три месеца след гласуването ѝ дава шанс на президента Румен Радев да покаже онова лице, което нацията обича да вижда – национално отговорно и загрижено, макар и в рамките на стеснените му правомощия при назначаване на служебен кабинет. Такъв отново стана належащ, след като и третата политическа сила, на която държавният глава връчи мандат – „Има такъв народ“, най-малката партия в 49-тото НС, върна празна папка. 

Механиката на политическия процес

Медиите забълбукаха от въпроси има ли конституционна криза, кой може да е министър-председател измежду записаните в Конституцията десетина души и кого би избрал Румен Радев. Председателя на Народното събрание Росен Желязков (ГЕРБ), който следва Бойко Борисов още от Столичната община? Гуверньора на БНБ Димитър Радев, издигнат още през 2015-та начело на централната банка от ГЕРБ? Или един от тримата подуправители – Андрей Гюров (ПП), Петър Чобанов (ДПС), Радослав Миленков, избран през 2019 г. от сглобката ГЕРБ–ДПС?

А може би председателя на Сметната палата Димитър Главчев (ГЕРБ), който беше депутат още от голямата победа на партията през лятото на 2009-та? Или някой от двамата му заместници – Горица Кожарева, издигната от „Патриотичния фронт“ за този пост през 2015 г., и Тошко Тодоров, също от ГЕРБ? Кожарева дори беше временен шеф на институцията с гласовете на ГЕРБ, БСП, ДПС и „Български възход“, след като през 2023 г. бързо бе отстранен Цветан Цветков от Реформаторския блок.

Като възможен кандидат отпадна омбудсманът Диана Ковачева, бивша правосъдна министърка в кабинет на ГЕРБ, отскоро съдийка в Европейския съд по правата на човека. А нейната заместничка Елена Чернева-Маркова подаде оставка тази седмица със следния мотив:

Заемането на политическа длъжност, каквато несъмнено е тази на министър-председател, е несъвместимо с упражняваните от мен функции като заместник-омбудсман.

Самоотстраниха се и централните банкери и Радев обясни защо:

Има етичен кодекс и правила на Европейската централна банка, които забраняват на управители и подуправители да заемат политически постове. Има колизия с националното законодателство, което е очевидно, но това, за което малко се говори, е, че има колизия с европейското законодателство. Управителят на централната банка и неговата роля са изрично дефинирани в договора за функционирането на Европейския съюз, протоколите към него, Устава на ЕЦБ, Устава на Европейската система на централни банки. Те са много експлицитни в това отношение, че не могат да се съвместяват тези длъжности. Етичният кодекс изрично посочва, че управителят трябва да избягва каквото и да е участие в политическия процес.

Изглежда, че бащите на промените в Конституцията не са били наясно с тези правила, вписвайки управителя на БНБ и подуправителите в селекцията за премиери. Така че кръгът изглежда широк само на пръв поглед, защото накъдето и да се обърне Румен Радев, взорът му попада на ГЕРБ. На когото и от този кръг да се спре, няма да избегне критиките за връзка с Борисов. Вследствие на продължилата повече от десетилетие доминация във властта на Бойко Борисов регулаторите и контролните органи са окупирани от кадри на ГЕРБ, а тук-там се мяркат и свързани с ДПС. 

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

Никой не е очаквал, че колегите от ГЕРБ ще свалят правителство и ще ни хвърлят на избори два месеца след приемането на промените в Конституцията,

каза съпредседателят на „Демократична България“ Христо Иванов по bTV

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

Същността

Въпреки несъгласията си с конституционните промени, които атакува и в Конституционния съд, президентът обяви, че ще обсъди предварително с партиите намеренията си и кандидата за премиер. С така проявената добронамереност и разум сигурно очаква да му върнат жеста с предварително съгласуване на кандидатите за министри, за да няма скандал при подписване на указа за назначаването на правителството.

Тези служебни министри ще управляват заедно с 49-тия парламент, който ще работи до полагането на клетва от новите избраници, което означава до юни. Експериментът с още близо 3 месеца действащо Народно събрание може да бъде използван от политиците за полезна за обществото политическа работа. Например да приемат тези закони, чието негласуване бави отпускането на втория транш от 653 млн. евро по Плана за възстановяване и устойчивост, а предстоят и трети, и четвърти за общо над 1,2 млрд. евро. 

Такива закони са приетият на първо четене миналата есен Закон за личния фалит, по който обаче не е работено впоследствие; пътната карта за енергетиката; законът за защита на лицата, подаващи сигнали или публично оповестяващи информация за нарушения. От ПП–ДБ смятат да внесат в парламента подготвения от Министерството на правосъдието проект на Закон за съдебната власт. Но дали ще получи коридор за обсъждане законът, трасиращ пътя към избори на Висш прокурорски съвет, Висш съдебен съвет, Инспекторат на съдебната власт и главен прокурор, предстои да се разбере.

Също така все още не е известно дали управлявалото доскоро мнозинство ПП–ДБ и ГЕРБ–СДС ще се заеме с избора поне на тези 85 членове на регулатори и контролни органи, за които е необходимо обикновено мнозинство. Идеята не е чужда на някои политици от ГЕРБ и ПП–ДБ. Със сигурност ще се наложи парламентът да избере омбудсман и негов заместник, при това без да губи време, тъй като през април Ковачева ще смени досегашния български съдия в ЕСПЧ Йонко Грозев. Продължават да са във висящо положение и управителят и подуправителят на НЗОК, които бяха първоначално избрани от парламента, а след скандал внесоха оставките си през декември 2023 г. Така Станимир Михайлов и Момчил Мавров тушираха възникналия тогава конфликт в сглобката, „помолила“ ги да подадат оставки. 

Тези и други назначения обаче трябва да намерят разрешение независимо от публично изразеното нежелание от съпредседателя на ПП Кирил Петков да се назначават хора преди избори, „когато е мътна водата“. Предложението за това беше отправено от лидера на ГЕРБ Бойко Борисов, който смята, че е по-добре двете формации да работят заедно, вместо да се противопоставят. Мандатите на мнозина в тези държавни органи са изтекли от години, а неизвестността как ще са разпределени силите в 50-тия парламент след изборите през юни прави атрактивна офертата на лидера на ГЕРБ. Освен че налива основи за бъдеща коалиция. Със сглобките вече е приключено.

По буквите: Ларкин

Post Syndicated from Зорница Христова original https://www.toest.bg/po-bukvite-larkin/

Високи прозорци“ от Филип Ларкин

По буквите: Ларкин

превод от английски Кристин Димитрова и Георги Пашов, София: Издателство за поезия ДА, 2024

За какво служат дните,

започва едно стихотворение на Филип Ларкин. В дните живеем, идва незабавният отговор. Почти детскоградински отговор, но пък и въпросът сякаш е такъв. И вижте как продължава – те идват, събуждат ни отново и отново. Идват, за да се радваме в тях.
И тук втори въпрос:

Къде да живеем освен в дните?

Какво ще рече това? Дали не е като в „Часовете“ при Майкъл Кънингам – времето на часовниците срещу вътрешното усещане за време и случване? Протяжността на времето срещу фрустрацията от неговата празнота, по-скоро от неговата запълненост с тривиални, ежедневни неща?

Да се върнем страница назад.

О, няма съмнение, че Арнолд не е егоист като мене. Той се ожени, за да не си отиде завинаги тя, и ето я тука деня и нощя.

Следва описание на брачния живот, което очевидно ужасява протагониста; ужасява го тъкмо с това, че бракът пълни с несвобода не дни, а години, задръства го, пълни го… с нищо. В какъв смисъл „с нищо“?

По буквите: Ларкин

Друго стихотворение. Героят е на гара, на която вижда влак за своя роден град, за Ковънтри. Събеседникът му го пита нещо за града на детството – и героят се сепва и казва: не, какво детство, просто там съм роден. И когато разказва неукрасените си и неовкусени спомени, добавя накрая, че не е виновно градчето, не е виновен Ковънтри, защото

Нищото, като нещото, се случва навсякъде.

Но защо „нищо“? Какво трябва да се случи в Ковънтри, в София, където и да било, за да бъде „нищото“ нещо? Какво трябва да има във „фотоалбума на една млада дама“, какво точно трябва да купят парите в „Пари“, за да не навяват тъга?

Както пише преводачката Кристин Димитрова в своя послеслов, Ларкин има двойствено отношение към Дилън Томас и поетите от неговото поколение. Ранното възхищение преминава в силно разграничение; като предшественик се припознава единствено Харди. Неволно си представям бясната динамика в поезията на Томас, онази сила, дето през зелен фитил извлича цветето и понякога завихря дори езика до помътняване, до непрозрачност, за да може да го накара да каже, че „и смъртта ще остане без царство“.

На този фон Филип Ларкин иронично отбелязва, че „емпириката казва друго“. Не само за смъртта, а за цялата жизнена сила, която като че ли тупти у Дилън Томас, цялата неизчерпаемост на жизнената енергия, която всъщност можем да проследим и малко по-назад, да я наречем байроническа, романтическа, сюблимна.

Ето това липсва в Ковънтри. Това липсва в дните.

Наречете го както щете – високи прозорци?

Това е старата „сюблимност“ на романтиците. И всичко – цялото живеене, всички тези дни – изяжда нейното място, нейната възможност за случване. Затова „високите прозорци“ идват в края на стихотворението, което започва с двамата млади, които се чукат и тя ползва диафрагма – възможно най-несакралното на пръв поглед начало, но това, което ще възпре разливането на мига в живеене, в непрестанно възпроизвеждаща се причинно-следствена връзка.

И този парадокс присъства навсякъде в поезията на Ларкин – тя е на пръв поглед ужасно неромантична, дори подигравателна към всички клишета на романтиците – детето, любовта, природата – насмешлива и изпитателна, готова да припява като някакъв съвременен Тил Уленшпигел they fuck you up, your mom and dad… – и в същото време болезнено романтична в копнежа си да стопира всичко в очакване на сюблимното, което е… какво?

Онова от живота, което би било равно по сила на смъртта.

Смъртта е сюблимен, надчовешки факт и протагонистът на Ларкин копнее за нещо в живота, което да ѝ е равно по ръст;

нещо, което да не е мираж, нито неумело самозалъгване, нито лъжа. Онова, което има предвид и Далчев в прочутото „не ме оставяй да загина, преди да съм живял“. Той копнее за това почти толкова силно, колкото всеки романтик; и толкова ясно описва неговото несъществуване, че то затрептява пред нас „в позлата и с изопнат такелаж“.

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

П.П. Ларкин е доста труден за превод по много причини. Радвам се, че е попаднал точно в ръцете на Георги Пашов и Кристин Димитрова. Препоръчвам горещо и нейния послеслов – там ще намерите всичко, което аз пропуснах.


В емблематичната си колонка, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка.

В ада без изход и ние бяхме…

Post Syndicated from Тоест original https://www.toest.bg/v-ada-bez-izhod-i-nie-byahme/

В ада без изход и ние бяхме...

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

(1994)
Йоан Ес. Поп
Превод от румънски Лора Ненковска


Йоан Ес. Поп (р. 1958) е един от живите класици на съвременната румънска поезия. Дебютира през 1994 г. със стихосбирката „Адът без изход“. Книгата му е истинско събитие на фона на оглушителната тишина, царяща в румънския литературен живот в първото десетилетие след промените. Йоан Ес. Поп работи в Музея на литературата в Букурещ и е автор на 13 стихосбирки и поетични антологии.

Лора Ненковска е преподавателка по средновековна и съвременна румънска литература и румънски език в СУ „Св. Климент Охридски“. Тя много обича да следи какво се случва в съвременната румънска (и не само) литература и е превела повече от 25 книги с проза, драматургия и поезия.


Според Екатерина Йосифова „четящият стихотворение сутрин… добре понася другите часове“ от деня. Убедени, че поезията държи умовете ни будни, а сърцата – отворени, в края на всеки месец ви предлагаме по едно стихотворение. Защото и в най-смутни времена доброто стихотворение е добра новина.

[$] The race to replace Redis

Post Syndicated from jzb original https://lwn.net/Articles/966631/

On March 21, Redis Ltd. announced that the Redisin-memory data store” project would now be
released under non-free, source-available licenses, starting with Redis 7.4. The
news is unwelcome, but not entirely unexpected. What is unusual with this situation is
the number of Redis alternatives to choose from; there are at least
four options to choose as a replacement for those who wish to stay
with free software, including a pre-existing fork called KeyDB and the Linux Foundation’s newly-announced Valkey project. The question now is which one(s)
Linux distributions, users, and providers will choose to take its place.

Винаги другите са тези, които се измъкват (по терлици)

Post Syndicated from original https://www.toest.bg/vinagi-drugitie-sa-tezi-koito-se-izmukvat-po-terlitsi/

Винаги другите са тези, които се измъкват (по терлици)

Ако на 17 март сте пропуснали да отпразнувате Деня на свети Патрик подобаващо, не унивайте. Съвсем спокойно и по всяко друго време може да извършите някоя от дейностите, с които се отбелязва празникът – да се закичите с трилистна детелина, да се облечете в зелено или да се почерпите с пинта „Гинес“. А ако пинтите станат повечко и се наложи, може дори да упражните т.нар. ирландско сбогуване.

Наименованието на последната „дейност“ все още не е сериозно навлязло в българския език, но самата тя – състояща се в това

да си тръгнеш от купон или друго събиране тихомълком и без да се сбогуваш

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

От практическа гледна точка „ирландското сбогуване“ несъмнено предотвратява загубата на време, тъй като се избягват ненужни формалности. Наскоро попаднах на изследване, проведено сред австралийци. Според резултатите от него хората, които систематично напускат купони, без да се сбогуват, спестяват по цели два дни на година¹. Макар и числото вероятно да варира според конкретния случай, личностните специфики на отделния човек и общоприетите нрави в различни култури, безспорно е, че безкрайните сбогувания в края на социални сбирки могат да погълнат минути, часове (а с натрупване очевидно и цели дни), които бихме могли да вложим в други (по презумпция) по-полезни дейности.

Но извън чисто практичната му полза „ирландското сбогуване“ също така ни предоставя възможност да разгледаме отблизо някои любопитни езикови особености, които от своя страна отразяват още по-любопитни културни, социални и исторически феномени – и то без риск да ни обвинят в неприлични обноски.

Смята се, че

изразът Irish goodbye всъщност произлиза не от Ирландия, а от Америка.

Макар че няма единодушна теория за появата му, според една от версиите, цитирана в базата данни с неологизми на университета „Райс“, изразът е разговорен и води началото си от Бостън, Масачузетс, a употребата му се отнася за някой, който напуска парти, бар или друго социално събиране, защото е пиян и иска да си тръгне, без да разговаря с никого и да разкрива нетрезвото си състояние.

Други, по-сантиментални теории свързват произхода на израза с т.нар. Ирландски картофен глад в средата на XIX век, който принуждава между един и два милиона души да eмигрират от Ирландия, голяма част от които впоследствие се заселват в Америка. Трети пък правят връзка между горните две теории, изтъквайки репутацията на ирландските имигранти и техните потомци като големи пиячи, на които често им се налага да практикуват „ирландското сбогуване“, поради което и самата практика започва да се нарича по този начин.

Както можем да предположим, макар и произходът на конкретния израз да е сравнително скорошен, самата практика е много по-стара, като лингвистите проследяват първообраза му не до другаде, а до родното място на добрите обноски – Англия. Използвайки възможността за пореден път да покажат два пръста² на древните си врагове от другата страна на Ламанша (който те, разбира се, наричат The English Channel), англичаните още от средата на XVIII век – като определение на страхливото оттегляне на французите по време на военни сражения³ – назовават практиката на напускане без сбогуване French leave, а в по-съвременен вариант тя съществува и като French exit.

От английския език изразът се разпространява и навлиза в испанския (despedirse a la francesca) и португалския (sair á francesca), а даже и в словенския (oditi po francosko), гръцкия (την κάνω/το σκάω αλά γαλλικά) и немския (sich auf französisch empfehlen), макар че там съществува и понятието einen polnischen Abgang machen („да направиш полски изход“).

Както може да се очаква, французите не остават длъжни на англичаните и на свой ред им показват една bras d’honneur, обозначавайки безцеремонното тръгване като filer a l’anglaise, тоест „измъкване по английски“. На свой ред цял набор от други езици заимстват израза, като например унгарският (angolosan távozik), румънският (a o sterge englezeste), полският (wyjść po angielsku), чешкият (vypařit se po anglicku), украинският („пiти по-англiйськи“) и руският („уйти по-английски“).

Италианците пък, явно предпочитайки да не заемат страна – или пък смятайки англичаните и французите за еднакво невъзпитани, – използват и двете разновидности: както andarsene alla francese, така и filarsela all’inglese.

Както съвсем намясто се отбелязва в статия по темата в Zeit Magazin,

винаги тези, които се измъкват, са другите.

Но не и според българския език, който – като никога! – в този случай се проявява доста по-възпитано и политкоректно от европейските си роднини.

Макар че ирландското, английското и френското сбогуване до известна степен вече са навлезли като фрази и в българския език, той по-скоро разчита на благозвучни, почти ономатопеични и винаги възвратни (тоест насочени не към друг, а към самия извършител на безцеремонното напускане) глаголи, за да назове въпросната практика, например: „изсулвам се“, „измъквам се“, „изнизвам се“, „изнасям се“, „спасявам се“, „чупя се“ и т.н. Някои от другите често използвани глаголи, освен възвратни, са и метафорични: „изпарявам се“, „омитам се“, „омъглявам се“.

А когато изразите съдържат някакво сравнение, се разчита по-скоро на конкретни образи от всекидневието, отколкото на стереотипизиране на цели народи, например: „измъквам се по терлици/пантофи/капли“, „изхлузвам се като мокра връв“, „изнизвам се през задния вход“ или „изпарявам се като дим“. Вероятно всички вие вече сте се досетили и за най-цветистия български израз за въпросната практика, който може и да не обижда ничия национална принадлежност, но със сигурност нарушава добрия тон. (Да, става дума точно за фразата, в която напускането тихомълком се сравнява с друга универсална „човещинка“, или измъкването като „газ“ из „бельо“.)

Тук все пак е справедливо да отбележим, че и в нарочените по-горе за неполиткоректни езици съществуват и „по-дипломатични“ изрази за практиката да се изнижеш без обяснения. В САЩ например като синонимни за Irish goodbye се използва и вече леко остарялото понятие houdini, по името на американския илюзионист, живял в края на XIX и началото на XX век и известен с ловкото си измъкване от белезници, усмирителни ризи и всякакви други примки, както и новопоявилият се (и вече навлязъл и сред младото поколение по света, включително и в България) глагол to ghost, от „призрак“. Французите пък, когато искат да спазят благоприличие и да не обиждат англичаните, използват израза partir comme un voleur („да напуснеш като крадец“).

За финал няма как да не се запитаме какво е положението в самата Ирландия. Според единия от тримата ирландци, до които се допитах, там не съществува конкретен израз, еквивалентен на „ирландско сбогуване“. Другите двама изобщо не ми отговориха, което – вярвам, ще се съгласите – е точно толкова грубо, колкото да си тръгнеш, без да се сбогуваш.

Но все пак изглежда, че не само изразът, а и практиката, поне до известна степен, са достигнали и до Изумрудения остров. Миналата година например гледахме ирландската комедия, взела „Оскар“ за най-добър късометражен игрален филм, чието заглавие – An Irish Goodbye – е директно заимствано от израза. И докато в „Баншите от Инишерин“ – другия ирландски фаворит от 2023 г. – изразът може изобщо да не се споменава, няма как да не отбележим, че в самия център на историята, която филмът разказва, е точно едно абсолютно безцеремонно сбогуване. (Или поне опит за такова, макар и то впоследствие да се превръща в разтегленото сбогуване от алтернативната дефиниция на израза, което – освен че става доста кърваво – трае не часове, а дни наред, отваря нови теми за разговор и претърпява вълнуващи обрати.)

Но дори и изразът Irish goodbye да не се използва в Ирландия, там сбогуването – както рязкото, така и разтегленото във времето и пространството – несъмнено е на почит10. Достатъчно е да споменем (без да се лъжем, че сме го чели) един от шедьоврите на ирландската литература: романа „Бдение над Финеган“ на Джеймс Джойс. Повествованието в него хем се разпростира подобно на болезнено дълго пиянско бълнуване, чийто край сякаш никога няма да настъпи (малко като настоящия текст), хем завършва напълно внезапно, без никакво предупреждение и по средата на изречението – съвсем в стила на ирландското сбогуване. 

1 Според въпросното проучване, цитирано в различни новинарски сайтове и социални медии в средата на март, са анкетирани 2000 австралийци, които посещават средно по 25 партита на година, като на всеки от тях му отнема средно по 45 минути да се сбогува, преди да си тръгне, което се равнява на 18 часа и 45 минути на година. Изследването се приписва на Института по управление на времето на Университета на Нов Южен Уелс в Сидни, но аз не откривам такъв институт на сайта на университета, нито пък споменаване на подобно изследване. Все пак изчисленията звучат правдоподобно.

2 Показването на два пръста е британският еквивалент на универсалния вулгарен знак със среден пръст. Легендата проследява появата на първия жест до Стогодишната война (1337–1453), когато французите пленявали английските стрелци с лък и им отрязвали показалеца и средния пръст, за да им попречат да използват лъка, а незаловените стрелци започнали да показват знака V със същите два пръста като символ на неподчинение на французите.

3 Сред историческите източници няма консенсус дали английското French leave предхожда френското filer a l’anglaise, или обратното, но повечето лингвисти смятат, че и двата израза са се появили в резултат на взаимни обиди в страхливост между френски и английски войници по време на Седемгодишната война (1756–1763), а след това са започнали да се използват като определение на случаите, когато гости на бал или прием си тръгвали, без да се сбогуват с домакините.

4 Според статия в Zeit Magazin от 2014 г., докато по-старият израз „да се сбогуваш по френски“ (sich auf französisch empfehlen/verabschieden) е по-популярен в Западна Германия, в Източна Германия по-често се използва изразът със сходно значение „да направиш полски изход“ (einen polnischen Abgang machen). В статията се цитира научно изследване на германиста Дирк Рамтор, според което вторият израз произлиза от годините след падането на Берлинската стена, когато германците са имали навика да се шегуват на гърба на поляците и да ги набеждават, че са крадливи.

5 В руския си вариант изразът даже се появява в сценария „Как-то так всё вышло…“, който Владимир Висоцки пише в началото на 70-те години: „Снова возникли разговоры, все забыли про барда, и он незаметно ускользнул с женщиной, которой взгляд так безошибочно засек. Так сказать, ушел по-английски.“

6 Като става дума за (само)рефлексивност, мой близък от Швеция се пошегува с пословичната скандинавска социална скованост и каза, че там практиката да си тръгнеш, без да се сбогуваш, се нарича просто „най-нормално напускане на купон“.

7 На основата на „ирландското сбогуване“, „английското изнизване“ и „френския изход“ се раждат и цяла серия шеговити вариации, например: British exit, вдъхновен от Брекзит, който означава да обявиш на всеослушание, че си тръгваш, и часове по-късно да те открият пиян в някой ъгъл; Jewish goodbye, тоест да се сбогуваш с всички и след това още дълго да не си тръгнеш; и Tokyo Sayonara, когато на тръгване се сбогуваш единствено с котката.

8 В горецитираната статия в Zeit Magazin се твърди – както логично бихме могли да предположим, – че в Ирландия все пак се използва английският израз to take French leave.

9 Макар че около популярната дефиниция на израза Irish goodbye като цяло има консенсус, някои източници твърдят, че освен с установеното си и широко разпространено значение, той може да означава и точно обратното – безкрайно дълго сбогуване на входната врата, типично за големи ирландски семейства (но не само), по време на което се отварят нови теми и се провеждат цели разговори.

10 Неизненадващо, житието на самия покровител на Ирландия и ирландците свети Патрик съдържа цял набор такива „сбогувания“ – той бива отвлечен от пирати от родната си Англия, впоследствие бяга от робство и плен в Ирландия и т.н.


В рубриката „От дума на дума“ Екатерина Петрова търси актуални, интересни или новопоявили се думи от нашето ежедневие и проследява често изненадващия им произход, развитието на значенията им във времето и взаимовръзките им с близки и далечни езици.

Stories from the SoC Part 1: IDAT Loader to BruteRatel

Post Syndicated from Tom Elkins original https://blog.rapid7.com/2024/03/28/stories-from-the-soc-part-1-idat-loader-to-bruteratel/

Stories from the SoC Part 1: IDAT Loader to BruteRatel

Rapid7’s Managed Detection and Response (MDR) team continuously monitors our customers’ environments, identifying emerging threats and developing new detections.

In August 2023, Rapid7 identified a new malware loader named the IDAT Loader. Malware loaders are a type of malicious software designed to deliver and execute additional malware onto a victim’s system. What made the IDAT Loader unique was the way in which it retrieved data from PNG files, searching for offsets beginning with 49 44 41 54 (IDAT).

At the time, the loader was seen being distributed via a FakeUpdates campaign. In two recent investigations, Rapid7’s Managed Detection & Response (MDR) observed the loader being used again. Based on the recent tactics, techniques and procedures observed (TTPs), we believe the activity is associated with financially motivated threat groups.

In this two-part blog series, we will examine the attack chain observed in two separate incidents, offering in-depth analysis of the malicious behavior detected. The incidents discussed in the series stem from opportunistic infections, wherein threat groups utilize malvertising and drive-by downloads in order to have their initial malicious payloads executed by users.

This first installment focuses on an incident triggered by a user downloading an application, which subsequently triggered the execution of the IDAT Loader and the BruteRatel C4 (BRC4) framework following initial access to a compromised asset.

Technical Analysis

Stage 1: The drive by

In a recent incident, Rapid7 observed a user navigate to a website that hosted popular Korean shows. Upon attempting to watch the video, the website redirected the user through various websites before ultimately directing the users browser into downloading a supposed application named AppFile_v1.1.exe. Threat actors utilize website redirection in order to make it difficult for network technologies to scan links for malicious content.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 1 – Attack Flow

Binary Analysis: Shaking off the Rust

After initial analysis of the binary AppFile_v1.1.exe, Rapid7 determined the program was written in Rust.

During execution, the program will query the name of the executable. If the executable’s name matches AppFile_v1.1.exe, the program will continue. Most sandboxes will rename the files (sometimes based on the hash) of submitted programs. This technique helps to evade sandboxes, ensuring the malicious functions are not run. If the program name does not match its original intended name,  the program will quit and display an error message, showing an image that a web page could not be loaded.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 2 – Error messages displayed by AppFile_v1.1.exe when checks fail

Next, the program will check to see if it resides within a debugger by querying the function IsDebuggerPresent. If the check passes, it will decrypt a hard-coded string that resolves to “Normal”. If not, the program will decrypt another hard-coded string that resolves to “Debugger” and then exit.

Once the anti-debug check passes, the program retrieves an encrypted string and XOR decrypts it, revealing the URL hxxps://cdn-network-services-001[.]com/update/minor/1/release.json.

The program will then perform anti-analysis techniques, specifically querying for the username and open process and comparing them to a list of known sandbox usernames and tools. The list of usernames and processes are also XOR-encrypted and are decrypted at runtime. Based on Open Source Intelligence, we determined that another malware known as Serpent Stealer contained a similar table of user names. See Appendix A below for the complete list.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Table 1 – Usernames and Known Sandbox Tools to Check Against
Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 3 – Sample Output from x64Debugger showing list of processes to check for

If any of the checks fail, the program will exit and display the message box. If the checks pass, the program will then utilize Rust library tokio-1.32.0/src/net/tcp/stream.rs in order to read in data from the decrypted URL and store the contents in memory.

Upon initial analysis, the downloaded data appeared to be encoded. Subsequently, the data is passed into a function tasked with decoding it. The decoding process involves reading each byte and subtracting the hexadecimal value 32.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 4 – Data Decoding Routine
Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 5 – Decoded downloaded bytes using CyberChef

After the downloaded data is decoded, the program XOR decrypts another string, revealing a path to the executable C:\Windows\system32\werfault.exe. Using syscalls, the program then does the following:

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Table 2 – Syscalls Used by Rust Loader

After analysis of the decoded binary, we determined that it was another executable written in Rust. The program’s executable contains a zip archive within the .rdata section. During execution, the program generates a folder with a randomly generated name in the %TEMP% directory and extracts the contents of the archive into this newly created folder.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 6 – ZIP Archive Contained Within New Rust Executable

The archive contained a DLL, msidcrl40.dll, an executable named live.exe and an encrypted file, dynatron.mdb. Initial analysis of the DLL msidcrl40.dll showed that the DLL’s signature was corrupted, indicating the DLL was tampered with. Further analysis showed that the DLL contained code related to the IDAT Loader.

IDAT Loader

After the rust program drops the contents of the zip archive, it then proceeds to execute the binary live.exe, which sideloads the DLL, msidcrl40.dll, containing the IDAT Loader code.

After the binary live.exe loads the DLL msidcrl40.dll, the DLL executes the function containing  the IDAT Loader. The IDAT then reads in encrypted contents contained within the file dynatron.mdb, searching for the offset 49 44 41 54 (IDAT) followed by C6 A5 79 EA. After decrypting the contents, the loader will then decompress the contents using RtlDecompressBuffer and execute additional code into a newly created process, cmd.exe.

The IDAT loader employs advanced techniques such as Process Doppelgänging and the Heaven’s Gate technique in order to initiate new processes and inject additional code.

The code contained within cmd.exe is responsible for decrypting the final payload and injecting it into a newly created process, msbuild.exe.

Using our IDAT Loader config extractor, we were able to extract the final payload and determined that it was SecTop RAT. During execution of the SecTop RAT, we observed that it communicated with the IP address 152.89.217[.]215.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 7 – SecTop RAT payload extracted by our IDAT Loader Python Script

Post-Exploitation: BRC4 Deployment

After the SecTop RAT was executed successfully, Rapid7 observed follow-on activity in which the threat actor executed another version of the IDAT loader from within the folder path C:\ProgramData\. We observed the following related files were dropped by the threat actor into C:\ProgramData:

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Table 2: Files Dropped by Threat Actor into C:/ProgramData\

After analysis of the files, we determined that rvm.exe was a renamed executable rvmsetup.exe, a legitimate tool that is a part of the VMWare Tools toolset. The binary is used to join a VMWare source virtual machine to an active directory domain. We also observed that the binary vmtools.dll had a corrupted signature, indicating the binary’s code was tampered with. We observed that the DLL vmtools.dll contained code related to the IDAT Loader.

During execution of the executable, rvm.exe, the program loads vmtools.dll. After vmtools.dll is loaded, the DLL is directed to execute a function that contains the IDAT Loader. The IDAT Loader proceeds to read in contents from within spank.mpg, searching for the same offset, 49 44 41 54 (IDAT) followed by C6 A5 79 EA. After decrypting the contents within spank.mpg, the IDAT Loader spawns a new process, cmd.exe, injecting additional code that is responsible for decrypting the final payload and injecting it into a newly created process, explorer.exe.

Using our static config extractor, we extracted the final payload, a 64-bit executable. During initial analysis of the final payload, we observed that the program utilized the API functions VirtualAlloc and VirtualProtect. During execution of the program, it utilized VirtualAlloc to read in and store additional code, including encrypted data, into a new region of memory. The program then called upon the function VirtualProtect, changing the newly allocated region of memory (containing the new code) to be executable. We also observed the 64 bit executable (obtained from the IDAT Loader python script) had the capability to perform process hollowing by starting a new process, notepad.exe, and injecting the code into the newly created process.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 8 – Final Payload showing Injection into notepad.exe

The newly allocated code was responsible for decrypting the encrypted data using RC4, copying the decrypted code into an allocated memory buffer via VirtualAlloc, and setting the memory buffer to have executable permission using VirtualProtect. Rapid7 determined the decrypted code was a Brute Ratel C4 (BRC4) “badger”.

Brute Ratel originated as a post-exploitation tool intended for penetration testers, designed to mimic adversary tactics as of December 2020. Its development aimed to replicate the functionality of established Command and Control (C2) software like Cobalt Strike, Mythic and Sliver. Following a successful compromise of a target, the attacker deploys the Brute Ratel “badger,” tasked with establishing communication with the attacker’s Command and Control domain.

During execution of the BRC4 program, we observed that it reached out to the domain updatenazure[.]com.

Stories from the SoC Part 1: IDAT Loader to BruteRatel
Figure 9 – Debugging BRC4 C2 Communication

After the BRC4 program was executed, we observed the threat actor attempting to enumerate the domain controller by using the command nltest /dclist.

Rapid7 Customers

InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections deployed and alerting on activity described:

  • Network Discovery – Nltest Enumerate Domain Controllers
  • Suspicious Process – Execution From Root of ProgramData
  • Suspicious Process – PowerShell Uncommon Upper And Lower Case Combinations
  • Suspicious Process – explorer.exe in Non-Standard Location

Appendix A: Known Sandbox Usernames and Analysis Tools

Usernames Processes
hbyldjtckyn1 httpdebuggerui.exe
lubi53an14cu immunitydebugger.exe
rgzcbuyrznreg ksdumperclient.exe
8lnfaai9qdjr httpanalyzerstdv7.exe
j6sha37ka ida64.exe
keecfmwgj 32dbg.exe
pwouqdtdq 64dbg.exe
qmis5df7u protection_id.exe
txwas1m2t vmsrvc.exe
uox1tzamo x32dbg.exe
rb5bnfur2 x64dbg.exe
cm0uegn4do x96dbg.exe
douyo8rv71 prl_cc.exe
paul jones windbg.exe
pxmduopvyx scylla.exe
fnbdsldtxy idau64.exe
gexwjqdjxg idaq64.exe
gjam1nxxvm idag64.exe
jcotj17dzx taskmgr.exe
05kvauqkpqk5 procexp.exe
64f2tkiqo5k5h procmon.exe
of20xqh4vl fiddler.exe
harry johnson dumpcap.exe
4tgiizslims df5serv.exe
bvjchrpnsxn ollydbg.exe
kfu0lqwgx5p rdpclip.exe
nok4zg7zhof vmusrvc.exe
ogjb6gqgk0o5 qemu-ga.exe
xplyvzr8sgc vboxtray.exe
ykj0egq7fze vmtoolsd.exe
ryjijkiroms pestudio.exe
nzap7ubvas1 vmacthlp.exe
9yjcpseyimh procexp64.exe
uhuqiuwoefu wireshark.exe
6o4kyhhjxbir prl_tools.exe
7wjlgx7pjlw4 importrec.exe
8nl0colnq5bq vmwaretray.exe
g2dbyldgzz8yo vmwareuser.exe
pqonjhvwexsst xenservice.exe
rdhj0cnfevzxf scylla_x86.exe
xmimmckziitdl scylla_x64.exe
l3cnbb8ar5b8 vboxservice.exe
vzy4jmh0jw02
21zlucunfi85
sal.rosenburg
defaultaccount
wdagutilityaccount

MITRE ATT&CK Techniques

Tactics Techniques Details
Initial Access Drive-by Compromise (T1189) Threat Actors utilize drive-by downloads in order to direct browsers to download their initial payloads without users consent
Execution User Execution: Malicious File (T1204.002) Users execute the binary AppFile_v1.1.exe
Execution Native API (T1106) The IDAT injector and IDAT loader are using Heaven’s Gate technique to evade detection
Defense Evasion Hijack Execution Flow: DLL Search Order Hijacking (T1574.001) run.exe loads a malicious wbxtrace.dll
Defense Evasion Process Injection (T1055) IDAT injector implements NtCreateSection + NtMapViewOfSection Code Injection technique to inject into cmd.exe process
Defense Evasion Deobfuscate/Decode Files or Information (T1140) msidcrl40.dll decrypts dynatron.mdb
Defense Evasion Process Injection: Process Doppelgänging (T1055.013) IDAT loader implements Process Doppelgänging technique to load the SecTop RAT
Defense Evasion Masquerading (T1036) dynatron.mdb file masqueraded to a .png file
Defense Evasion Virtualization/Sandbox Evasion: Time Based Evasion (T1497.003) Execution delays are performed by several stages throughout the attack flow

IOCs

IOC Sha256 Notes
AppFile_v1.1.exe A3A5E7011335A2284E2D4F73FD464FF129F0C9276878A054C1932BC50608584B Rust Loader responsible for downloading IDAT Loader
msidcrl40.dll 02D5E281689EC2D4AB8AC19C93321A09113E5D8FA39380A7021580EA1887B7A5 Malicious DLL executed by live.exe
dynatron.mdb C5C52331B208CAD19DC710786E26AC55090FFCA937410D76C53569D731F0BB92 Encrypted payload decrypted by msidcrl40.dll
vmtools.dll BEFE0DF365F0E2DC05225470E45FDF03609F098A526D617C478B81AC6BB9147F Malicious DLL executed by rvm.exe
spank.mpg E05E561C5118EFDBCA113CA231C527B62E59A4BFFAE3BD374F7B4FCDD10E7D90 Encrypted payload decrypted by vmtools.dll
hxxps://cdn-network-services-001[.]com/update/minor/1/release.json Downloads additional Rust binary containing IDAT Loader
152.89.217[.]215 SecTop RAT domain
updatenazure[.]com BRC4 Domain

References

Article URL
Uncovering the “Serpent” https://malware.news/t/uncovering-the-serpent/76253
Process Doppelgänging https://malware.news/t/uncovering-the-serpent/76253
Analysis of “Heaven’s Gate” part 1 https://sachiel-archangel.medium.com/analysis-of-heavens-gate-part-1-62cca0ace6f0
A Deep Dive Into Malicious Direct Syscall Detection https://www.paloaltonetworks.com/blog/security-operations/a-deep-dive-into-malicious-direct-syscall-detection/
Fake Update Utilizes New IDAT Loader To Execute StealC and Lumma Infostealers https://www.rapid7.com/blog/post/2023/08/31/fake-update-utilizes-new-idat-loader-to-execute-stealc-and-lumma-infostealers/

Krones real-time production line monitoring with Amazon Managed Service for Apache Flink

Post Syndicated from Florian Mair original https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/

Krones provides breweries, beverage bottlers, and food producers all over the world with individual machines and complete production lines. Every day, millions of glass bottles, cans, and PET containers run through a Krones line. Production lines are complex systems with lots of possible errors that could stall the line and decrease the production yield. Krones wants to detect the failure as early as possible (sometimes even before it happens) and notify production line operators to increase reliability and output. So how to detect a failure? Krones equips their lines with sensors for data collection, which can then be evaluated against rules. Krones, as the line manufacturer, as well as the line operator have the possibility to create monitoring rules for machines. Therefore, beverage bottlers and other operators can define their own margin of error for the line. In the past, Krones used a system based on a time series database. The main challenges were that this system was hard to debug and also queries represented the current state of machines but not the state transitions.

This post shows how Krones built a streaming solution to monitor their lines, based on Amazon Kinesis and Amazon Managed Service for Apache Flink. These fully managed services reduce the complexity of building streaming applications with Apache Flink. Managed Service for Apache Flink manages the underlying Apache Flink components that provide durable application state, metrics, logs, and more, and Kinesis enables you to cost-effectively process streaming data at any scale. If you want to get started with your own Apache Flink application, check out the GitHub repository for samples using the Java, Python, or SQL APIs of Flink.

Overview of solution

Krones’s line monitoring is part of the Krones Shopfloor Guidance system. It provides support in the organization, prioritization, management, and documentation of all activities in the company. It allows them to notify an operator if the machine is stopped or materials are required, regardless where the operator is in the line. Proven condition monitoring rules are already built-in but can also be user defined via the user interface. For example, if a certain data point that is monitored violates a threshold, there can be a text message or trigger for a maintenance order on the line.

The condition monitoring and rule evaluation system is built on AWS, using AWS analytics services. The following diagram illustrates the architecture.

Architecture Diagram for Krones Production Line Monitoring

Almost every data streaming application consists of five layers: data source, stream ingestion, stream storage, stream processing, and one or more destinations. In the following sections, we dive deeper into each layer and how the line monitoring solution, built by Krones, works in detail.

Data source

The data is gathered by a service running on an edge device reading several protocols like Siemens S7 or OPC/UA. Raw data is preprocessed to create a unified JSON structure, which makes it easier to process later on in the rule engine. A sample payload converted to JSON might look like the following:

{
  "version": 1,
  "timestamp": 1234,
  "equipmentId": "84068f2f-3f39-4b9c-a995-d2a84d878689",
  "tag": "water_temperature",
  "value": 13.45,
  "quality": "Ok",
  "meta": {      
    "sequenceNumber": 123,
    "flags": ["Fst", "Lst", "Wmk", "Syn", "Ats"],
    "createdAt": 12345690,
    "sourceId": "filling_machine"
  }
}

Stream ingestion

AWS IoT Greengrass is an open source Internet of Things (IoT) edge runtime and cloud service. This allows you to act on data locally and aggregate and filter device data. AWS IoT Greengrass provides prebuilt components that can be deployed to the edge. The production line solution uses the stream manager component, which can process data and transfer it to AWS destinations such as AWS IoT Analytics, Amazon Simple Storage Service (Amazon S3), and Kinesis. The stream manager buffers and aggregates records, then sends it to a Kinesis data stream.

Stream storage

The job of the stream storage is to buffer messages in a fault tolerant way and make it available for consumption to one or more consumer applications. To achieve this on AWS, the most common technologies are Kinesis and Amazon Managed Streaming for Apache Kafka (Amazon MSK). For storing our sensor data from production lines, Krones choose Kinesis. Kinesis is a serverless streaming data service that works at any scale with low latency. Shards within a Kinesis data stream are a uniquely identified sequence of data records, where a stream is composed of one or more shards. Each shard has 2 MB/s of read capacity and 1 MB/s write capacity (with max 1,000 records/s). To avoid hitting those limits, data should be distributed among shards as evenly as possible. Every record that is sent to Kinesis has a partition key, which is used to group data into a shard. Therefore, you want to have a large number of partition keys to distribute the load evenly. The stream manager running on AWS IoT Greengrass supports random partition key assignments, which means that all records end up in a random shard and the load is distributed evenly. A disadvantage of random partition key assignments is that records aren’t stored in order in Kinesis. We explain how to solve this in the next section, where we talk about watermarks.

Watermarks

A watermark is a mechanism used to track and measure the progress of event time in a data stream. The event time is the timestamp from when the event was created at the source. The watermark indicates the timely progress of the stream processing application, so all events with an earlier or equal timestamp are considered as processed. This information is essential for Flink to advance event time and trigger relevant computations, such as window evaluations. The allowed lag between event time and watermark can be configured to determine how long to wait for late data before considering a window complete and advancing the watermark.

Krones has systems all around the globe, and needed to handle late arrivals due to connection losses or other network constraints. They started out by monitoring late arrivals and setting the default Flink late handling to the maximum value they saw in this metric. They experienced issues with time synchronization from the edge devices, which lead them to a more sophisticated way of watermarking. They built a global watermark for all the senders and used the lowest value as the watermark. The timestamps are stored in a HashMap for all incoming events. When the watermarks are emitted periodically, the smallest value of this HashMap is used. To avoid stalling of watermarks by missing data, they configured an idleTimeOut parameter, which ignores timestamps that are older than a certain threshold. This increases latency but gives strong data consistency.

public class BucketWatermarkGenerator implements WatermarkGenerator<DataPointEvent> {
private HashMap <String, WatermarkAndTimestamp> lastTimestamps;
private Long idleTimeOut;
private long maxOutOfOrderness;
}

Stream processing

After the data is collected from sensors and ingested into Kinesis, it needs to be evaluated by a rule engine. A rule in this system represents the state of a single metric (such as temperature) or a collection of metrics. To interpret a metric, more than one data point is used, which is a stateful calculation. In this section, we dive deeper into the keyed state and broadcast state in Apache Flink and how they’re used to build the Krones rule engine.

Control stream and broadcast state pattern

In Apache Flink, state refers to the ability of the system to store and manage information persistently across time and operations, enabling the processing of streaming data with support for stateful computations.

The broadcast state pattern allows the distribution of a state to all parallel instances of an operator. Therefore, all operators have the same state and data can be processed using this same state. This read-only data can be ingested by using a control stream. A control stream is a regular data stream, but usually with a much lower data rate. This pattern allows you to dynamically update the state on all operators, enabling the user to change the state and behavior of the application without the need for a redeploy. More precisely, the distribution of the state is done by the use of a control stream. By adding a new record into the control stream, all operators receive this update and are using the new state for the processing of new messages.

This allows users of Krones application to ingest new rules into the Flink application without restarting it. This avoids downtime and gives a great user experience as changes happen in real time. A rule covers a scenario in order to detect a process deviation. Sometimes, the machine data is not as easy to interpret as it might look at first glance. If a temperature sensor is sending high values, this might indicate an error, but also be the effect of an ongoing maintenance procedure. It’s important to put metrics in context and filter some values. This is achieved by a concept called grouping.

Grouping of metrics

The grouping of data and metrics allows you to define the relevance of incoming data and produce accurate results. Let’s walk through the example in the following figure.

Grouping of metrics

In Step 1, we define two condition groups. Group 1 collects the machine state and which product is going through the line. Group 2 uses the value of the temperature and pressure sensors. A condition group can have different states depending on the values it receives. In this example, group 1 receives data that the machine is running, and the one-liter bottle is selected as the product; this gives this group the state ACTIVE. Group 2 has metrics for temperature and pressure; both metrics are above their thresholds for more than 5 minutes. This results in group 2 being in a WARNING state. This means group 1 reports that everything is fine and group 2 does not. In Step 2, weights are added to the groups. This is needed in some situations, because groups might report conflicting information. In this scenario, group 1 reports ACTIVE and group 2 reports WARNING, so it’s not clear to the system what the state of the line is. After adding the weights, the states can be ranked, as shown in step 3. Lastly, the highest ranked state is chosen as the winning one, as shown in Step 4.

After the rules are evaluated and the final machine state is defined, the results will be further processed. The action taken depends on the rule configuration; this can be a notification to the line operator to restock materials, do some maintenance, or just a visual update on the dashboard. This part of the system, which evaluates metrics and rules and takes actions based on the results, is referred to as a rule engine.

Scaling the rule engine

By letting users build their own rules, the rule engine can have a high number of rules that it needs to evaluate, and some rules might use the same sensor data as other rules. Flink is a distributed system that scales very well horizontally. To distribute a data stream to several tasks, you can use the keyBy() method. This allows you to partition a data stream in a logical way and send parts of the data to different task managers. This is often done by choosing an arbitrary key so you get an evenly distributed load. In this case, Krones added a ruleId to the data point and used it as a key. Otherwise, data points that are needed are processed by another task. The keyed data stream can be used across all rules just like a regular variable.

Destinations

When a rule changes its state, the information is sent to a Kinesis stream and then via Amazon EventBridge to consumers. One of the consumers creates a notification from the event that is transmitted to the production line and alerts the personnel to act. To be able to analyze the rule state changes, another service writes the data to an Amazon DynamoDB table for fast access and a TTL is in place to offload long-term history to Amazon S3 for further reporting.

Conclusion

In this post, we showed you how Krones built a real-time production line monitoring system on AWS. Managed Service for Apache Flink allowed the Krones team to get started quickly by focusing on application development rather than infrastructure. The real-time capabilities of Flink enabled Krones to reduce machine downtime by 10% and increase efficiency up to 5%.

If you want to build your own streaming applications, check out the available samples on the GitHub repository. If you want to extend your Flink application with custom connectors, see Making it Easier to Build Connectors with Apache Flink: Introducing the Async Sink. The Async Sink is available in Apache Flink version 1.15.1 and later.


About the Authors

Florian Mair is a Senior Solutions Architect and data streaming expert at AWS. He is a technologist that helps customers in Europe succeed and innovate by solving business challenges using AWS Cloud services. Besides working as a Solutions Architect, Florian is a passionate mountaineer, and has climbed some of the highest mountains across Europe.

Emil Dietl is a Senior Tech Lead at Krones specializing in data engineering, with a key field in Apache Flink and microservices. His work often involves the development and maintenance of mission-critical software. Outside of his professional life, he deeply values spending quality time with his family.

Simon Peyer is a Solutions Architect at AWS based in Switzerland. He is a practical doer and is passionate about connecting technology and people using AWS Cloud services. A special focus for him is data streaming and automations. Besides work, Simon enjoys his family, the outdoors, and hiking in the mountains.

How Amazon optimized its high-volume financial reconciliation process with Amazon EMR for higher scalability and performance

Post Syndicated from Jeeshan Khetrapal original https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/

Account reconciliation is an important step to ensure the completeness and accuracy of financial statements. Specifically, companies must reconcile balance sheet accounts that could contain significant or material misstatements. Accountants go through each account in the general ledger of accounts and verify that the balance listed is complete and accurate. When discrepancies are found, accountants investigate and take appropriate corrective action.

As part of Amazon’s FinTech organization, we offer a software platform that empowers the internal accounting teams at Amazon to conduct account reconciliations. To optimize the reconciliation process, these users require high performance transformation with the ability to scale on demand, as well as the ability to process variable file sizes ranging from as low as a few MBs to more than 100 GB. It’s not always possible to fit data onto a single machine or process it with one single program in a reasonable time frame. This computation has to be done fast enough to provide practical services where programming logic and underlying details (data distribution, fault tolerance, and scheduling) can be separated.

We can achieve these simultaneous computations on multiple machines or threads of the same function across groups of elements of a dataset by using distributed data processing solutions. This encouraged us to reinvent our reconciliation service powered by AWS services, including Amazon EMR and the Apache Spark distributed processing framework, which uses PySpark. This service enables users to process files over 100 GB containing up to 100 million transactions in less than 30 minutes. The reconciliation service has become a powerhouse for data processing, and now users can seamlessly perform a variety of operations, such as Pivot, JOIN (like an Excel VLOOKUP operation), arithmetic operations, and more, providing a versatile and efficient solution for reconciling vast datasets. This enhancement is a testament to the scalability and speed achieved through the adoption of distributed data processing solutions.

In this post, we explain how we integrated Amazon EMR to build a highly available and scalable system that enabled us to run a high-volume financial reconciliation process.

Architecture before migration

The following diagram illustrates our previous architecture.

Our legacy service was built with Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. We processed the data sequentially using Python. However, due to its lack of parallel processing capability, we frequently had to increase the cluster size vertically to support larger datasets. For context, 5 GB of data with 50 operations took around 3 hours to process. This service was configured to scale horizontally to five ECS instances that polled messages from Amazon Simple Queue Service (Amazon SQS), which fed the transformation requests. Each instance was configured with 4 vCPUs and 30 GB of memory to allow horizontal scaling. However, we couldn’t expand its capacity on performance because the process happened sequentially, picking chunks of data from Amazon Simple Storage Service (Amazon S3) for processing. For example, a VLOOKUP operation where two files are to be joined required both files to be read in memory chunk by chunk to obtain the output. This became an obstacle for users because they had to wait for long periods of time to process their datasets.

As part of our re-architecture and modernization, we wanted to achieve the following:

  • High availability – The data processing clusters should be highly available, providing three 9s of availability (99.9%)
  • Throughput – The service should handle 1,500 runs per day
  • Latency – It should be able to process 100 GB of data within 30 minutes
  • Heterogeneity – The cluster should be able to support a wide variety of workloads, with files ranging from a few MBs to hundreds of GBs
  • Query concurrency – The implementation demands the ability to support a minimum of 10 degrees of concurrency
  • Reliability of jobs and data consistency – Jobs need to run reliably and consistently to avoid breaking Service Level Agreements (SLAs)
  • Cost-effective and scalable – It must be scalable based on the workload, making it cost-effective
  • Security and compliance – Given the sensitivity of data, it must support fine-grained access control and appropriate security implementations
  • Monitoring – The solution must offer end-to-end monitoring of the clusters and jobs

Why Amazon EMR

Amazon EMR is the industry-leading cloud big data solution for petabyte-scale data processing, interactive analytics, and machine learning (ML) using open source frameworks such as Apache Spark, Apache Hive, and Presto. With these frameworks and related open-source projects, you can process data for analytics purposes and BI workloads. Amazon EMR lets you transform and move large amounts of data in and out of other AWS data stores and databases, such as Amazon S3 and Amazon DynamoDB.

A notable advantage of Amazon EMR lies in its effective use of parallel processing with PySpark, marking a significant improvement over traditional sequential Python code. This innovative approach streamlines the deployment and scaling of Apache Spark clusters, allowing for efficient parallelization on large datasets. The distributed computing infrastructure not only enhances performance, but also enables the processing of vast amounts of data at unprecedented speeds. Equipped with libraries, PySpark facilitates Excel-like operations on DataFrames, and the higher-level abstraction of DataFrames simplifies intricate data manipulations, reducing code complexity. Combined with automatic cluster provisioning, dynamic resource allocation, and integration with other AWS services, Amazon EMR proves to be a versatile solution suitable for diverse workloads, ranging from batch processing to ML. The inherent fault tolerance in PySpark and Amazon EMR promotes robustness, even in the event of node failures, making it a scalable, cost-effective, and high-performance choice for parallel data processing on AWS.

Amazon EMR extends its capabilities beyond the basics, offering a variety of deployment options to cater to diverse needs. Whether it’s Amazon EMR on EC2, Amazon EMR on EKS, Amazon EMR Serverless, or Amazon EMR on AWS Outposts, you can tailor your approach to specific requirements. For those seeking a serverless environment for Spark jobs, integrating AWS Glue is also a viable option. In addition to supporting various open-source frameworks, including Spark, Amazon EMR provides flexibility in choosing deployment modes, Amazon Elastic Compute Cloud (Amazon EC2) instance types, scaling mechanisms, and numerous cost-saving optimization techniques.

Amazon EMR stands as a dynamic force in the cloud, delivering unmatched capabilities for organizations seeking robust big data solutions. Its seamless integration, powerful features, and adaptability make it an indispensable tool for navigating the complexities of data analytics and ML on AWS.

Redesigned architecture

The following diagram illustrates our redesigned architecture.

The solution operates under an API contract, where clients can submit transformation configurations, defining the set of operations alongside the S3 dataset location for processing. The request is queued through Amazon SQS, then directed to Amazon EMR via a Lambda function. This process initiates the creation of an Amazon EMR step for Spark framework implementation on a dedicated EMR cluster. Although Amazon EMR accommodates an unlimited number of steps over a long-running cluster’s lifetime, only 256 steps can be running or pending simultaneously. For optimal parallelization, the step concurrency is set at 10, allowing 10 steps to run concurrently. In case of request failures, the Amazon SQS dead-letter queue (DLQ) retains the event. Spark processes the request, translating Excel-like operations into PySpark code for an efficient query plan. Resilient DataFrames store input, output, and intermediate data in-memory, optimizing processing speed, reducing disk I/O cost, enhancing workload performance, and delivering the final output to the specified Amazon S3 location.

We define our SLA in two dimensions: latency and throughput. Latency is defined as the amount of time taken to perform one job against a deterministic dataset size and the number of operations performed on the dataset. Throughput is defined as the maximum number of simultaneous jobs the service can perform without breaching the latency SLA of one job. The overall scalability SLA of the service depends on the balance of horizontal scaling of elastic compute resources and vertical scaling of individual servers.

Because we had to run 1,500 processes per day with minimal latency and high performance, we choose to integrate Amazon EMR on EC2 deployment mode with managed scaling enabled to support processing variable file sizes.

The EMR cluster configuration provides many different selections:

  • EMR node types – Primary, core, or task nodes
  • Instance purchasing options – On-Demand Instances, Reserved Instances, or Spot Instances
  • Configuration options – EMR instance fleet or uniform instance group
  • Scaling optionsAuto Scaling or Amazon EMR managed scaling

Based on our variable workload, we configured an EMR instance fleet (for best practices, see Reliability). We also decided to use Amazon EMR managed scaling to scale the core and task nodes (for scaling scenarios, refer to Node allocation scenarios). Lastly, we chose memory-optimized AWS Graviton instances, which provide up to 30% lower cost and up to 15% improved performance for Spark workloads.

The following code provides a snapshot of our cluster configuration:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Performance

With our migration to Amazon EMR, we were able to achieve a system performance capable of handling a variety of datasets, ranging from as low as 273 B to as high as 88.5 GB with a p99 of 491 seconds (approximately 8 minutes).

The following figure illustrates the variety of file sizes processed.

The following figure shows our latency.

To compare against sequential processing, we took two datasets containing 53 million records and ran a VLOOKUP operation against each other, along with 49 other Excel-like operations. This took 26 minutes to process in the new service, compared to 5 days to process in the legacy service. This improvement is almost 300 times greater over the previous architecture in terms of performance.

Considerations

Keep in mind the following when considering this solution:

  • Right-sizing clusters – Although Amazon EMR is resizable, it’s important to right-size the clusters. Right-sizing mitigates a slow cluster, if undersized, or higher costs, if the cluster is oversized. To anticipate these issues, you can calculate the number and type of nodes that will be needed for the workloads.
  • Parallel steps – Running steps in parallel allows you to run more advanced workloads, increase cluster resource utilization, and reduce the amount of time taken to complete your workload. The number of steps allowed to run at one time is configurable and can be set when a cluster is launched and any time after the cluster has started. You need to consider and optimize the CPU/memory usage per job when multiple jobs are running in a single shared cluster.
  • Job-based transient EMR clusters – If applicable, it is recommended to use a job-based transient EMR cluster, which delivers superior isolation, verifying that each task operates within its dedicated environment. This approach optimizes resource utilization, helps prevent interference between jobs, and enhances overall performance and reliability. The transient nature enables efficient scaling, providing a robust and isolated solution for diverse data processing needs.
  • EMR Serverless – EMR Serverless is the ideal choice if you prefer not to handle the management and operation of clusters. It allows you to effortlessly run applications using open-source frameworks available within EMR Serverless, offering a straightforward and hassle-free experience.
  • Amazon EMR on EKS – Amazon EMR on EKS offers distinct advantages, such as faster startup times and improved scalability resolving compute capacity challenges—which is particularly beneficial for Graviton and Spot Instance users. The inclusion of a broader range of compute types enhances cost-efficiency, allowing tailored resource allocation. Furthermore, Multi-AZ support provides increased availability. These compelling features provide a robust solution for managing big data workloads with improved performance, cost optimization, and reliability across various computing scenarios.

Conclusion

In this post, we explained how Amazon optimized its high-volume financial reconciliation process with Amazon EMR for higher scalability and performance. If you have a monolithic application that’s dependent on vertical scaling to process additional requests or datasets, then migrating it to a distributed processing framework such as Apache Spark and choosing a managed service such as Amazon EMR for compute may help reduce the runtime to lower your delivery SLA, and also may help reduce the Total Cost of Ownership (TCO).

As we embrace Amazon EMR for this particular use case, we encourage you to explore further possibilities in your data innovation journey. Consider evaluating AWS Glue, along with other dynamic Amazon EMR deployment options such as EMR Serverless or Amazon EMR on EKS, to discover the best AWS service tailored to your unique use case. The future of the data innovation journey holds exciting possibilities and advancements to be explored further.


About the Authors

Jeeshan Khetrapal is a Sr. Software Development Engineer at Amazon, where he develops fintech products based on cloud computing serverless architectures that are responsible for companies’ IT general controls, financial reporting, and controllership for governance, risk, and compliance.

Sakti Mishra is a Principal Solutions Architect at AWS, where he helps customers modernize their data architecture and define their end-to-end data strategy, including data security, accessibility, governance, and more. He is also the author of the book Simplify Big Data Analytics with Amazon EMR. Outside of work, Sakti enjoys learning new technologies, watching movies, and visiting places with family.

[$] Declarative partitioning in PostgreSQL

Post Syndicated from daroc original https://lwn.net/Articles/965508/

Keith Fiske gave a talk
(with
slides
) about the state of partitioning — splitting a large
table into smaller tables for performance reasons — in
PostgreSQL at
SCALE
this year. He spoke about the existing support for partitioning, what work still
needs to be done, and what place existing partitioning tools, like his own

pg_partman
, still have as PostgreSQL gains more built-in features.

Отговорност за щетите в Министерството на електронното управление

Post Syndicated from Bozho original https://blog.bozho.net/blog/4246

Онзи ден Борисов каза, че преговорният екип на ГЕРБ се е борил за това министър на електронното управление да остане Йоловски. Мисля, че е важно да маркирам този факт, защото поне вече е ясно кой носи отговорност за щетите, нанесени там в последните месеци.

В министерството има общо 9 дирекции, главен секретар и една изпълнителна агенция. За последните 9 месеца са уволнени, помолени да напуснат, принудени да напуснат или преместени: главния секретар, изпълнителния директор на агенцията и директорите на 8 от 9-те дирекции.

И тази своеобразна чистка е само една от многото причини за липсата на резултати. Още в края на есента писах, че нямам очаквания, че политическото ръководство на МЕУ ще се справи със задачите, а напредъкът по управленската програма беше основно заради това, което свършихме в парламента. И това е разбираемо – при това разбиване на министерството, няма как там да се работи продуктивно.

Политиката за електронно управление е изключително важна за цялостното развитие на страната – за намаляване на административната тежест, за повече проследимост и прозрачност, за киберсигурността. И има нужда да бъдат придвижвани напред компетентно и систематично – нещо, което в последните 9 месеца се случваше в парламента, но далеч не толкова в МЕУ.

Материалът Отговорност за щетите в Министерството на електронното управление е публикуван за пръв път на БЛОГодаря.

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/966961/

Security updates have been issued by Fedora (perl-Data-UUID, python-pygments, and thunderbird), Mageia (clojure, grub2, kernel,kmod-xtables-addons,kmod-virtualbox, kernel-linus, nss firefox, nss, python3, python, tcpreplay, and thunderbird), Oracle (nodejs:18), Red Hat (.NET 6.0 and dnsmasq), SUSE (avahi and python39), and Ubuntu (curl, linux-intel-iotg, linux-intel-iotg-5.15, unixodbc, and util-linux).

Хронология на неосъществилата се ротация

Post Syndicated from Bozho original https://blog.bozho.net/blog/4244

Малко хронология на неосъществилата се ротация:

На 17-ти март Мария Габриел предложи: ротация на премиера и вицепремиера, без смяна на министри, и отлагане на подписването на споразумение за неопределено време.

ППДБ отказахме, защото за нас споразумението беше ключово.

На 19-ти март Мария Габриел внесе несъгласуван състав на Министерския съвет на втория ден от седемте за изпълнение на мандата без логично обяснение защо.

На 24-ти март Николай Денков предложи ротация на премиера и вицепремиера, без смяна на министри, но с подписано споразумение.

ГЕРБ отказаха. Вчера отказаха и повторно аналогично предложение с втория мандат, но с номиниран от тях премиер.

Разликата между предложенията на двете страни е ясна – споразумението. А какво има в него?

Съдебна реформа, реформа на службите, избор на независими регулатори, избор на органи на съдебната власт без гарантирани места за никого.
Все неща, без които държавата не може да върви напред. Неща, които щяха да бъдат протакани, отлагани и подменяни, ако ги няма черно на бяло.
И затова отиваме на избори – защото изглежда ГЕРБ са решили, че предпочитат избори пред това да имат твърд ангажимент по тези реформи, а ние (противно на обвиненията) не искаме да стоим във властта самоцелно, без да правим тези фундаментални за страната промени.

А всички „лакърдии“ от преговорния процес са шум и отклоняване на вниманието – кой с кого се срещал, какви имена задраскал, кой какво поискал, кой колко бил обиден и т.н.

България може да реши фундаменталните си проблеми само с независима съдебна система (без политици да назначават хора по върховете ѝ), с независими регулатори и с работещи служби. И това е най-трудната, но и най-важната политическа задача.

Материалът Хронология на неосъществилата се ротация е публикуван за пръв път на БЛОГодаря.

Our new theory of change

Post Syndicated from Ben Durbin original https://www.raspberrypi.org/blog/theory-of-change-2024/

One of the Raspberry Pi Foundation’s core values is our focus on impact. This means that we are committed to learning from the best available evidence, and to being rigorous and transparent about the difference we’re making.

A smiling girl holding a robot buggy in her lap

Like many charities, an important part of our approach to achieving and measuring our impact is our theory of change. We are excited to launch a newly refreshed theory of change that reflects our mission and strategy to ensure that young people can realise their full potential through the power of computing and digital technologies.

What is a theory of change?

A theory of change describes the difference an organisation aims to make in the world, the actions it takes to achieve this, and the underlying assumptions about how its actions will create change.

Two learners sharing a laptop in a coding session.

It’s like a good cake recipe. It describes the ingredients and tools that are required, how these are combined, and what the results should be. But a theory of change goes further: it also addresses why you need the cake in the first place, and the reasons why the recipe will produce such a good cake if you follow it correctly!

What is the change we want to make?

Our theory of change begins with a statement of the problem that needs solving: too many young people are missing out on the enormous opportunities from digital technologies, and access to opportunities to learn depends too much on who you are and where you were born.

We want to see a world where young people can take advantage of the opportunities that computers and digital technologies offer to transform their own lives and communities, to contribute to society, and to help address the world’s challenges.

Learners in a computing classroom.

To help us empower young people to do this, we have identified three broad sets of outcomes that we should target, measure, and hold ourselves accountable for. These map roughly to the COM-B model of behaviour change. This model suggests that for change to be achieved, people need a combination of capabilities, opportunities, and motivation.

Our identified outcomes are that we support young people to:

  1. Build knowledge and skills in computing
  2. Understand the opportunities and risks associated with new technologies
  3. Develop the mindsets to confidently engage with technological change

How do we make a difference?

We work at multiple levels throughout education systems and society, which together will achieve deep and long-lasting change for young people. We design learning experiences and initiatives that are fun and engaging, including hundreds of free coding and computing projects, the Coolest Projects showcase for young tech creators, and the European Astro Pi Challenge, which gives young people the chance to run their computer programs in space.

Three learners working at laptops.

We also support teachers, youth workers, volunteers, and parents to develop their skills and knowledge, and equip them to inspire young people and help them learn. For example, The Computing Curriculum provides a complete bank of free lesson plans and other resources, and Experience AI is our educational programme that includes everything teachers need to deliver lessons on artificial intelligence and machine learning in secondary schools.

Finally, we aim to elevate the state of computing education globally by advocating for policy and systems change, and undertaking our own original research to deepen our understanding of how young people learn about computing.

How will we use our theory of change?

Our theory of change is an important part of our approach to evaluating the impact of our resources and programmes, and it informs all our monitoring and evaluation plans. These plans identify the questions we want to answer, key metrics to monitor, and the data sources we use to understand the impact we’re having and to gather feedback to improve our impact in future.

An educator teaches students to create with technology.

The theory of change also informs a shared outcomes framework that we are applying consistently across all of our products. This framework supports planning and helps keep us focused as we consider new opportunities to further our mission.

A final role our theory of change plays is to help communicate our mission to other stakeholders, and explain how we can work with our partners and communities to achieve change.

You can read our new theory of change here and if you have any questions or feedback on it, please do get in touch.

The post Our new theory of change appeared first on Raspberry Pi Foundation.

Hardware Vulnerability in Apple’s M-Series Chips

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/03/hardware-vulnerability-in-apples-m-series-chips.html

It’s yet another hardware side-channel attack:

The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. By loading the contents into the CPU cache before it’s actually needed, the DMP, as the feature is abbreviated, reduces latency between the main memory and the CPU, a common bottleneck in modern computing. DMPs are a relatively new phenomenon found only in M-series chips and Intel’s 13th-generation Raptor Lake microarchitecture, although older forms of prefetchers have been common for years.

[…]

The breakthrough of the new research is that it exposes a previously overlooked behavior of DMPs in Apple silicon: Sometimes they confuse memory content, such as key material, with the pointer value that is used to load other data. As a result, the DMP often reads the data and attempts to treat it as an address to perform memory access. This “dereferencing” of “pointers”—meaning the reading of data and leaking it through a side channel—­is a flagrant violation of the constant-time paradigm.

[…]

The attack, which the researchers have named GoFetch, uses an application that doesn’t require root access, only the same user privileges needed by most third-party applications installed on a macOS system. M-series chips are divided into what are known as clusters. The M1, for example, has two clusters: one containing four efficiency cores and the other four performance cores. As long as the GoFetch app and the targeted cryptography app are running on the same performance cluster—­even when on separate cores within that cluster­—GoFetch can mine enough secrets to leak a secret key.

The attack works against both classical encryption algorithms and a newer generation of encryption that has been hardened to withstand anticipated attacks from quantum computers. The GoFetch app requires less than an hour to extract a 2048-bit RSA key and a little over two hours to extract a 2048-bit Diffie-Hellman key. The attack takes 54 minutes to extract the material required to assemble a Kyber-512 key and about 10 hours for a Dilithium-2 key, not counting offline time needed to process the raw data.

The GoFetch app connects to the targeted app and feeds it inputs that it signs or decrypts. As its doing this, it extracts the app secret key that it uses to perform these cryptographic operations. This mechanism means the targeted app need not perform any cryptographic operations on its own during the collection period.

Note that exploiting the vulnerability requires running a malicious app on the target computer. So it could be worse. On the other hand, like many of these hardware side-channel attacks, it’s not possible to patch.

Slashdot thread.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close