Visual Studio, Slack i trojany z Redmond: o czym nie pisaliśmy w ubiegłym tygodniu

Microsoft opublikował pierwszą wersję poglądową środowiska Visual Studio 2022. To istotna informacja z kilku powodów. Przede wszystkim potwierdza to, co powinno być oczywiste już wcześniej, czyli to że wersja 2019 nie będzie aktualizowana w nieskończoność.

Studio od kilku lat mocno przyspiesza z terminarzem aktualizacji i wersje 2015, 2017 i w szczególności 2019 otrzymują pakiety nowości czyniące owe środowiska wyraźnie bogatszymi niż w momencie premiery. Środowisko nie zmieniło się jednak w "rolling release", model biznesowy na to nie pozwala (istnieją przecież także wersje płatne!).

Główny przełom, który istotnie uzasadnia zmianę wersji, a nie "pchanie" nowości do 2019, jest przejście devenv na 64 bity. Program rósł ponad przyzwoitość już od dłuższego czasu i problem był na tyle duży, że niektóre działania środowiska zostały oddelegowane do procesów-satelitów. W przyciwnym wypadku, IDE dobiłoby do limitu pamięci dla 32-bitowych aplikacji nawet w przypadku mniejszych projektów. Spóźniona migracja na 64 bity usunie ten problem.

Reszta zmian jest ewolucyjna, jak nowe diagramy w profilerze, większe możliwości hot reload, czy wstępna zgodność z C++ 20. Ciekawi eksponowanie obsługi MAUI (dostępnej oczywiście już wcześniej), czyli zbioru bibliotek do tworzenia przenośnego między systemami GUI. Jest to coś, czego Windows Forms nigdy się nie nauczył.

"Firmowy" komunikator Slack, potocznie nazywany korporacyjnym IRC-em, pozwoli lepiej udawać punktualność. Oto staje się możliwe planowanie wysyłania wiadomości z wyprzedzeniem. Poza zabawnym scenariuszem, gdzie "cześć wszystkim" zostanie wysłane, gdy autor jeszcze leży w łóżku/pije kawę, możliwość wysyłania zaplanowanych wiadomości ma też inne zastosowania.

Jak zapewne zauważył niejeden pracownik większej firmy, wysyłanie wiadomości współpracownikowi gdy jest na obiedzie bywa nietaktowne. Firmowe konwenanse mogą na przykład zawierać niepisaną regułę "pisz do niego na obiedzie tylko jeżeli produkcja się wywali". Zmniejszanie źródeł rozproszenia jest wysoce wskazane, a w wielu scenariuszach nie można sobie pozwolić na zostawienie telefonu bez opieki/uwagi na biurku.

Zamiast zapomnieć o wysłaniu pytań, z którymi "wypada trochę poczekać", będziemy mogli zautomatyzować ich wysłanie w późniejszym czasie.

Specjalista ds. cyberbezpieczeństwa, Kevin Beaumont, zwrócił uwagę na skalę interesującego zjawiska, którego przykłady przytacza Karsten Hahn z G DATA. Trwają oto ataki wykorzystujące stworzone za pomocą Netfilter SDK sterowniki sieciowe. Sterowniki te są... podpisane przez Microsoft! Zaufany podpis cyfrowy sterownika jest warunkiem otrzymania przez niego dostępu do wysokich uprawnień

Ten bardzo ważny mechanizm bezpieczeństwa, wprowadzony w 64-bitowej wersji systemu Windows Vista, jest podatny na ataki logistyczne: skradzione, ale nieodwołane klucze podpisów cyfrowych. Ponieważ teraz sterowniki WHQL podpisuje tylko Microsoft, słabym punktem proces weryfikacji stosowany w Redmond.

Przy braku podwójnego podpisywania nie wiadomo, kto zlecił podpisanie złośliwego (lub możliwego do łatwego wykorzystania jako złośliwy) sterownika. Co gorsza, podpisane przez Microsoft pliki są traktowane jako "bezpieczne z założenia". Defender wykrywa już część z nich jako złośliwe oprogramowanie, ale samo zjawisko jest dziwne. Jak do tego doszło?

O całej sprawie jest zaskakująco cicho, choć jest poważna. Wynika to z braku wielu konkretów poza "jest źle" i "złośliwy kod podpisany przez Microsoft", poza tym materia jest niekoniecznie przystępna i łatwa do wytłumaczenia. Gdy o złośliwych sterownikach będzie wiadomo więcej, na pewno wrócimy do tematu.