Secrets of building a debuggable runtime: Learn how language implementors sol...Dev_Events
Bjørn Vårdal, J9VM Software Developer, IBM, @bvaardal
New language runtimes appear all the time, but most of them die young. Failure can be attributed to
different reasons, but an important factor is that lack of support can limit the community’s and
industry’s willingness to adopt the new language.
Quicker development and improved serviceability allows emerging languages to overcome this obstacle.
By building on the proven technology available in Eclipse OMR, language developers can get more than
performance and stability; you also get tools that help you quickly debug your language runtime,
allowing you to provide competitive serviceability.
From this presentation, you will learn how to enable Eclipse OMR’s mature debugging features in your
language runtime, and also how Eclipse OMR can assist with development and debugging
Evaluation of Container Virtualized MEGADOCK System in Distributed Computing ...Kento Aoyama
This document evaluates the performance of container virtualization using Docker for a bioinformatics application called MEGADOCK. Two experiments were conducted:
1) MEGADOCK was run on a physical machine with and without Docker, showing a 6.32% performance overhead with Docker. With NVIDIA Docker on GPU, performance was comparable to native.
2) MEGADOCK was run on Azure VMs with and without Docker, showing comparable scalability. Docker performance was around 6x faster than VMs.
The results show that Docker introduces small overhead for compute-intensive applications like MEGADOCK. Docker provides advantages of environment isolation and portability without significant performance costs.
"Applications, programming languages, and libraries that leverage sophisticated network hardware capabilities have a natural advantage when used in today’s and tomorrow’s high-performance and data center computer environments. Modern RDMA based network interconnects provides incredibly rich functionality (RDMA, Atomics, OS-bypass, etc.) that enable low-latency and high-bandwidth communication services. The functionality is supported by a variety of interconnect technologies such as InfiniBand, RoCE, iWARP, Intel OPA, Cray’s Aries/Gemini, and others. OFA organization and LinuxRDMA community have been playing a predominant role in the enablement efficient and vendor agnostic software stack for those interconnects. Over the last decade, the community has developed variety user/kernel level protocols and libraries that enable a variety of applications over RDMA including MPI, SHMEM, NFS over RDMA, IPoIB, and many others."
"With the emerging availability server platforms based on ARM CPU architecture, it is important to understand ARM integrates with RDMA hardware and software eco-system. In this talk, we will overview ARM architecture and system software stack. We will discuss how ARM CPU interacts with network devices and accelerators. In addition, we will share our experience in enabling RDMA software stack (OFED/MOFED Verbs) and one-sided communication libraries (Open UCX, OpenSHMEM/SHMEM) on ARM and share preliminary evaluation results."
Watch the video presentation: http://wp.me/p3RLHQ-gyO
Learn more: https://www.openfabrics.org/index.php/abstracts-agenda.html
Sign up for our insideHPC Newsletter: http://insidehpc.com/newsletter
A Linux device driver summary:
1. Device drivers are implemented as kernel modules that can be dynamically loaded and unloaded. They provide access to hardware devices through the file system.
2. There are three main types of device drivers: character, block, and network. Character drivers provide a stream of bytes interface, block drivers handle block-based storage, and network drivers manage network interfaces.
3. The file_operations structure contains function pointers that drivers implement to handle operations like open, close, read, and write on character devices. This structure associates the driver with a major/minor number range allocated using functions like alloc_chrdev_region.
Exascale Computing Project - Driving a HUGE Change in a Changing Worldinside-BigData.com
In this video from the OpenFabrics Workshop in Austin, Al Geist from ORNL presents: Exascale Computing Project - Driving a HUGE Change in a Changing World.
"In this keynote, Mr. Geist will discuss the need for future Department of Energy supercomputers to solve emerging data science and machine learning problems in addition to running traditional modeling and simulation applications. In August 2016, the Exascale Computing Project (ECP) was approved to support a huge lift in the trajectory of U.S. High Performance Computing (HPC). The ECP goals are intended to enable the delivery of capable exascale computers in 2022 and one early exascale system in 2021, which will foster a rich exascale ecosystem and work toward ensuring continued U.S. leadership in HPC. He will also share how the ECP plans to achieve these goals and the potential positive impacts for OFA."
Learn more: https://exascaleproject.org/
and
https://www.openfabrics.org/index.php/abstracts-agenda.html
Sign up for our insideHPC Newsletter: https://www.openfabrics.org/index.php/abstracts-agenda.html
TMPA-2017: Tools and Methods of Program Analysis
3-4 March, 2017, Hotel Holiday Inn Moscow Vinogradovo, Moscow
Dl-Check: Dynamic Potential Deadlock Detection Tool for Java Programs
Nikita Koval, Dmitry Tsitelov, Roman Elizarov, Devexperts
For video follow the link: https://youtu.be/uyQvsxVL_TI
Would like to know more?
Visit our website:
www.tmpaconf.org
www.exactprosystems.com/events/tmpa
Follow us:
https://www.linkedin.com/company/exactpro-systems-llc?trk=biz-companies-cym
https://twitter.com/exactpro
Disaster Recovery and Ceph Block Storage: Introducing Multi-Site MirroringJason Dillaman
This document introduces Ceph's multi-site mirroring feature for disaster recovery of RBD block storage. It uses a journal-based approach to log all image modifications and asynchronously replicate the journal across data centers. The rbd-mirror daemon is responsible for replaying the journal on remote clusters to achieve consistency. This allows RBD workloads to seamlessly failover and failback between sites, providing protection against data center failures.
A tour of (advanced) Akka features in 40 minutesJohan Janssen
These are the slides for my Akka presentation at JavaLand in 2017. It covers most Akka features like (remote) actors, clusters, FSM, Akka HTTP and persistence. It's explained on a high level to get an idea on what is possible with Akka.
With Java 9 modules coming to us soon, you want your existing code to be fully ready for the module system. Making code modular can be a daunting task, but Java 9 comes with a number features to ease migration. This includes automatic modules, the unnamed module and a number of command line arguments.
In this talk we will look at examples of migrating real code. It discusses common problems youll run into during migration, leading to practical tips and the ability to set realistic goals. Its also a good way to understand the module system itself and the various migration paths it supports. This talk is an excellent preparation to start migrating your own code.
* Understanding modules and the module path
* Automatic modules
* Mixing classpath and modulepath
* Dealing with reflection
* Escape switches
* Jdeps
All topics will be based on examples of often used libraries and frameworks.
Slides of my Alexa session at JavaLand in 2017. This session shows how you can use Alexa. For instance by buying standard hardware by Amazon like the Echo Dot, or building it yourself with a Raspberry Pi and an opensource Java application. Next to that I showed how to develop your own Alexa skills in Java and deploy them automatically with Maven to AWS Lambda. AWS Lambda is a serverless solution from Amazon.
Docker Azure Friday OSS March 2017 - Developing and deploying Java & Linux on...Patrick Chanezon
This document provides an overview of developing and deploying Java applications on Azure using Docker. It discusses using Docker to build Java applications, running containers, and deploying stacks. It also covers Docker Enterprise Edition, including subscriptions, certifications, and security features. Finally, it demonstrates using Docker on Azure, such as with Azure Container Service, and shows examples of building, running, and deploying Java applications with Docker.
The document discusses modularization in engineering projects. It defines modularization as fabricating and assembling minor or major plant sections offsite. Modularization can help move labor hours offsite to more productive environments through preassembly and prefabrication. The key benefits are cost reductions through improved productivity and schedule reductions. However, modularization also has cost implications that must be considered in an economic evaluation. Optimizing the proportion of labor hours moved offsite is important. Engineering and procurement are impacted through increased planning requirements for modular projects. Critical success factors include module fabrication and the decision making process.
The document provides an overview of key components of Linux including processor management using processes and scheduling, file management using a hierarchical directory structure and permissions, memory management using virtual memory and paging, device management through device drivers and identifiers, and the command line interface for navigating the file system and running commands. It describes processes like fork() and exec() for managing processes, and concepts like virtual addressing and page tables for memory management. Device management in Linux treats all devices as files that are accessed through device drivers defined by a major and minor number.
This document discusses the top 5 metrics to monitor in Kubernetes applications. It identifies 5 layers to monitor: 1) the application layer, 2) the services layer, 3) the Kubernetes deployment layer, 4) the Kubernetes internals layer, and 5) the host/node layer. For each layer, it provides example metrics and thresholds to monitor to check that layer is performing as expected. The overall document provides guidance on monitoring all aspects of a Kubernetes application from the application and services down through the underlying Kubernetes infrastructure and hosts.
OpenACC is a programming model for parallel computing on CPUs and GPUs. A performance portable molecular simulation achieved 11.7x speedup on a GPU compared to CPU using OpenACC. With simple compiler directives, a program's parallel code can run on different processor architectures with good performance. OpenACC allows for quicker development through portability and performance across systems like ARM, POWER, Sunway, and x86 CPUs and GPUs with only minor code changes of under 100 lines.
This document discusses building hermetic systems without Docker. It defines hermetic systems as airtight and pure, with well-defined inputs and outputs. It discusses sources of non-determinism like external libraries and services that can introduce "leaks". It proposes using Clojure components and embedding services like Elasticsearch to build deterministic, reproducible systems. Components are reusable units with well-defined dependencies and lifecycles. Embedding services isolates the system from external changes. Randomness and time can also introduce non-determinism but may be modeled as reproducible services. The goal is to evaluate systems, identify leaks, and design trade-offs to build robust, hermetic systems.
JSON, by now, became a regular part of most applications and services. Do we, how ever, really want to transfer human readable information or are we looking for a binary protocol to be as debuggable as JSON? CBOR the Concise Binary Object Representation offers the best of JSON + an extremely efficient, binary representation.
http://www.cbor.io
BlueStore, A New Storage Backend for Ceph, One Year InSage Weil
BlueStore is a new storage backend for Ceph OSDs that consumes block devices directly, bypassing the local XFS file system that is currently used today. It's design is motivated by everything we've learned about OSD workloads and interface requirements over the last decade, and everything that has worked well and not so well when storing objects as files in local files systems like XFS, btrfs, or ext4. BlueStore has been under development for a bit more than a year now, and has reached a state where it is becoming usable in production. This talk will cover the BlueStore design, how it has evolved over the last year, and what challenges remain before it can become the new default storage backend.
Disaster Recovery and Ceph Block Storage: Introducing Multi-Site MirroringJason Dillaman
This document introduces Ceph's multi-site mirroring feature for disaster recovery of RBD block storage. It uses a journal-based approach to log all image modifications and asynchronously replicate the journal across data centers. The rbd-mirror daemon is responsible for replaying the journal on remote clusters to achieve consistency. This allows RBD workloads to seamlessly failover and failback between sites, providing protection against data center failures.
A tour of (advanced) Akka features in 40 minutesJohan Janssen
These are the slides for my Akka presentation at JavaLand in 2017. It covers most Akka features like (remote) actors, clusters, FSM, Akka HTTP and persistence. It's explained on a high level to get an idea on what is possible with Akka.
With Java 9 modules coming to us soon, you want your existing code to be fully ready for the module system. Making code modular can be a daunting task, but Java 9 comes with a number features to ease migration. This includes automatic modules, the unnamed module and a number of command line arguments.
In this talk we will look at examples of migrating real code. It discusses common problems youll run into during migration, leading to practical tips and the ability to set realistic goals. Its also a good way to understand the module system itself and the various migration paths it supports. This talk is an excellent preparation to start migrating your own code.
* Understanding modules and the module path
* Automatic modules
* Mixing classpath and modulepath
* Dealing with reflection
* Escape switches
* Jdeps
All topics will be based on examples of often used libraries and frameworks.
Slides of my Alexa session at JavaLand in 2017. This session shows how you can use Alexa. For instance by buying standard hardware by Amazon like the Echo Dot, or building it yourself with a Raspberry Pi and an opensource Java application. Next to that I showed how to develop your own Alexa skills in Java and deploy them automatically with Maven to AWS Lambda. AWS Lambda is a serverless solution from Amazon.
Docker Azure Friday OSS March 2017 - Developing and deploying Java & Linux on...Patrick Chanezon
This document provides an overview of developing and deploying Java applications on Azure using Docker. It discusses using Docker to build Java applications, running containers, and deploying stacks. It also covers Docker Enterprise Edition, including subscriptions, certifications, and security features. Finally, it demonstrates using Docker on Azure, such as with Azure Container Service, and shows examples of building, running, and deploying Java applications with Docker.
The document discusses modularization in engineering projects. It defines modularization as fabricating and assembling minor or major plant sections offsite. Modularization can help move labor hours offsite to more productive environments through preassembly and prefabrication. The key benefits are cost reductions through improved productivity and schedule reductions. However, modularization also has cost implications that must be considered in an economic evaluation. Optimizing the proportion of labor hours moved offsite is important. Engineering and procurement are impacted through increased planning requirements for modular projects. Critical success factors include module fabrication and the decision making process.
The document provides an overview of key components of Linux including processor management using processes and scheduling, file management using a hierarchical directory structure and permissions, memory management using virtual memory and paging, device management through device drivers and identifiers, and the command line interface for navigating the file system and running commands. It describes processes like fork() and exec() for managing processes, and concepts like virtual addressing and page tables for memory management. Device management in Linux treats all devices as files that are accessed through device drivers defined by a major and minor number.
This document discusses the top 5 metrics to monitor in Kubernetes applications. It identifies 5 layers to monitor: 1) the application layer, 2) the services layer, 3) the Kubernetes deployment layer, 4) the Kubernetes internals layer, and 5) the host/node layer. For each layer, it provides example metrics and thresholds to monitor to check that layer is performing as expected. The overall document provides guidance on monitoring all aspects of a Kubernetes application from the application and services down through the underlying Kubernetes infrastructure and hosts.
OpenACC is a programming model for parallel computing on CPUs and GPUs. A performance portable molecular simulation achieved 11.7x speedup on a GPU compared to CPU using OpenACC. With simple compiler directives, a program's parallel code can run on different processor architectures with good performance. OpenACC allows for quicker development through portability and performance across systems like ARM, POWER, Sunway, and x86 CPUs and GPUs with only minor code changes of under 100 lines.
This document discusses building hermetic systems without Docker. It defines hermetic systems as airtight and pure, with well-defined inputs and outputs. It discusses sources of non-determinism like external libraries and services that can introduce "leaks". It proposes using Clojure components and embedding services like Elasticsearch to build deterministic, reproducible systems. Components are reusable units with well-defined dependencies and lifecycles. Embedding services isolates the system from external changes. Randomness and time can also introduce non-determinism but may be modeled as reproducible services. The goal is to evaluate systems, identify leaks, and design trade-offs to build robust, hermetic systems.
JSON, by now, became a regular part of most applications and services. Do we, how ever, really want to transfer human readable information or are we looking for a binary protocol to be as debuggable as JSON? CBOR the Concise Binary Object Representation offers the best of JSON + an extremely efficient, binary representation.
http://www.cbor.io
BlueStore, A New Storage Backend for Ceph, One Year InSage Weil
BlueStore is a new storage backend for Ceph OSDs that consumes block devices directly, bypassing the local XFS file system that is currently used today. It's design is motivated by everything we've learned about OSD workloads and interface requirements over the last decade, and everything that has worked well and not so well when storing objects as files in local files systems like XFS, btrfs, or ext4. BlueStore has been under development for a bit more than a year now, and has reached a state where it is becoming usable in production. This talk will cover the BlueStore design, how it has evolved over the last year, and what challenges remain before it can become the new default storage backend.
Digital Signage Systems - The Modern Hacker's OutreachZero Science Lab
The document provides information on several digital signage systems and related security issues, including:
1) Eight cases of vulnerabilities found in different digital signage systems are described, such as remote code execution, SQL injection, authentication bypass, and more.
2) Common attack vectors for digital signage systems are explained, including exposed management interfaces, known vulnerabilities, default or hard-coded credentials, lack of authentication and authorization, and more.
3) Details are given on specific exploits against systems like Cayin, QiHang Media, UBICOD Medivision, and others, demonstrating privilege escalation, unauthorized file access and deletion, and in some cases gaining full remote code execution.
The document analyzes the cybersecurity of 5 building management system (BMS) components from 4 vendors. It finds that a significant number of BMS devices are directly accessible from the internet, and the components share common design flaws like default credentials, lack of input sanitization, and insecure firmware updates. The research uncovered over 100 vulnerabilities in total, demonstrating how an attacker could achieve unauthenticated remote code execution on the systems and potentially impact over 10 million people. It recommends vendors improve security standards for BMS products.
Exploitation and distribution of setuid and setgid binaries on Linux systemsZero Science Lab
Abstract—In an era of internet freedom, lack of control and supervision, every system is exposed to various attackers and malicious users which, given the right circumstances, are able to cause colossal damage. A single security vulnerability can be the reason for a business’ downfall, therefore significant attention needs to be paid to said systems’ security to avoid such issues. Unix-like filesystems define certain access rights flags, named setuid and setgid, which allow users to execute files with the permissions of the file’s owner or group. This can be exploited to gain unprivileged access using buffer overflow attacks. I performed tests by running a script to collect the files in Ubuntu, Debian, Slackware, Fedora and CentOS to find the files with the setuid and setgid bits set. My aim is to determine which distribution is the most secure one and whether Slackware, considering it’s known for its’ secure design and characteristics, will prove its’ reputation. The results show that Debian and CentOS have e least amount of exploitable binaries, while Slackware and Fedora have the most.
Web Vulnerabilities And Exploitation - Compromising The WebZero Science Lab
One of the main problems of all big companies is how their applications are secured from cyber attacks. New types of vulnerabilities and attack vectors are being developed every day, therefore they pose a potential threat to all applications that rely on some kind of web technology. This document explains the most common and most dangerous web attacks as well as techniques how to secure your infrastructure from being compromised. We focus on SQL injections, XSS, CSRF, RFI/LFI and Server Side Includes. We discuss the attack vectors of web vulnerabilities and exploitation schemas. However, regardless of the security measures taken and defenses being deployed, there will always be a way in. Nevertheless, security analysis provide a valuable insight that can grant the advantage over said attackers and allow us to stay one step ahead.
This document contains the results of a second comparative penetration test conducted by a team of security specialists at Zero Science Lab against two cloud-based Web Application Firewall (WAF) solutions: Incapsula and Cloudflare. This test was designed to bypass security controls in place, in any possible way, circumventing whatever filters they have. Given the rise in application-level attacks, the goal of the test was to provide IT managers of online businesses with a comparison of these WAFs against real-world threats in simulated real-world conditions.
This document contains the results of a comparative penetration test conducted by a team of security specialists at Zero Science Lab against three ‘leading’ web application firewall solutions. Our goal was to bypass security controls in place, in any way we can, circumventing whatever filters they have. This report also outlines the setup and configuration process, as well as a detailed security assessment.
Преоптоварување на баферот и безбедносни механизми на меморијата PPTZero Science Lab
Заштитата на податоците отсекогаш била важна, уште од минатото се користеле одредени алгоритми за шифрирање со цел информациите да бидат прочитани само од лицето за кое што биле наменети т.е лицето кое што го поседувал клучот за дешифрирање.
Преоптоварување на баферот и безбедносни механизми на меморијатаZero Science Lab
Преоптоварување на баферот претставува компјутерски пропуст како резултат на внесување низа на карактери во бафер преку функции кои не ги проверуваат границите на бројот на дозволени карактери што можат да бидат внесени. Структурираниот справувач со испади или SEH претставува механизам имплементиран во Microsoft Windows оперативните системи којшто претставува податочна структура т.е поврзана листа составена од најмалце едно поле во кое се сместени податоци и еден покажувач кон следниот елемент. ASLR механизмот е имплементиран кај Linux и Windows оперативните системи, и овозможува случајност на адресите (адресниот простор). DEP или ‘Data Execution Prevention’ претставува механизам со хардверска и софтверска имплементација за спречување на извршување на инструкции во делови од меморијата зададени од напаѓачот
This document provides an overview of the Open Web Application Security Project (OWASP) Bulgaria chapter. It introduces the chapter leader and discusses OWASP's mission to improve software security. The document outlines membership benefits and encourages participation in OWASP projects and events. It also summarizes the OWASP Top 10 project, which identifies the most critical web application security risks.
Grsecurity - Theoretical and Practical ApplicationZero Science Lab
This document discusses GRSECURITY and PAX, which are Linux kernel security patches that provide protections against memory corruption bugs and exploits. Some key features include PaX, which implements address space layout randomization and W^X protections, as well as role-based access control and enhanced auditing. The patches contain options for detection, prevention, and protection of the address space against modification.
Maximiliano Soler gives a presentation on using Google to gather information without sophisticated mechanisms. He demonstrates how to use Google search operators ("dorks") to find vulnerable products, error messages, sensitive files and passwords, foot holds for access, and more. He recommends securing servers and applications, disabling directory browsing, not publishing sensitive info without authentication, and analyzing website search traffic for security.
Анализа на оддалечена експлоатациjа во Linux кернел
1. Факултет за Информатички Науки
и Компjутерско Инжeнерство
Насока: Мрежни Технологии
http://www.finki.ukim.mk
Дипломска Работа
Анализа на оддалечена експлоатациjа во Linux
кернел
18.11.2016, 19 страни
Ментор: д-р Боро Jакимовски
Кандидат: Ева Танаскоска - 122124 {[email protected]}
Установа: Универзитет Св. Кирил и Методиj - Скопjе
Клучни зборови: Linux, оддалечена експлоатациjа, ранливост, подсистем, кернел
3. Абстракт
Голем дел од серверите, паметните уреди и суперкомпjутерите работат на Linux кернелот.
Сеприсутноста на Linux е една од причините зошто безбедноста на овоj кернел треба да биде
приоритетна при дизаjн и имплементациjа.
Во ова истражување се опфатени ранливости кои се jавно познати и имаат доделен CVE
идентификатор во National Vulnerability Database. Истражувањето покажа дека наjранливиот
подсистем од Linux кернелот во однос на оддалечена експлоатациjа е мрежниот стек. Одредени
мрежни драjвери и имплементации на мрежни податочни системи исто така сочинуваат значаен
дел од познатите мрежни ранливости во Linux.
Причините се употреба на небезбеден програмски jазик и ранливости кои настануваат како
резултат на несоодветни проверки на влез, што може да се заклучи по CWE класите кои се
наjприсутни во анализираните 192 ранливости. Мнозинството од ранливостите се оценети како
средно-ризични, но и броjот на критични ранливости е релативно висок.
2
4. Глава 1
Вовед
Linux историjата започнува во 1991 како личен проект на Линус Торвалдс со цел да креира
нов бесплатен кернел за оперативен систем. Од тогаш, Linux кернелот постоjано е надградуван
и напредува. Linux кернелот е еден од наjголемите софтверски проекти со отворен код во
историjата. На секои 2-3 месеци има стабилни верзии, секоjа со значителни нови карактеристики
и подобрени перформанси. Ратата на промени во кернелот постоjано се зголемува како што се
зголемува и броjот на развивачи и компании кои придонесуваат со своjот код.
Флексибилноста на Linux кернелот е причина зошто истиот се употребува во наjразлични
средини, од телефони, возила, дома´кински апарати, до сервери и суперкомпjутери. Ме´гутоа,
овоj брз развоj и различни примени доа´гаат со одредена цена. Секоjа нова промена во кернелот
претставува потенциjална опасност бидеj´ки често се прават промени кои иако се потполно
функционални, претставуваат нова закана за корисниците на овоj кернел доколку не се извршат
одредени безбедносни проверки, наjчесто во подсистеми и функции кои примаат и манипулираат
влез од корисник, мрежа или друга функциjа.
Главниот проблем потекнува од фактот што Linux, како и сите UNIX базирани системи, не
се развиени со фокус на безбедноста, [1] што гарантира голем броj на безбедносни пропусти.
Областа во коjа UNIX-базираните системи се наjслаби во минатото беше заштита против падови
и попречување на нормалната работа на системот - што воедно важи и до ден денес. Недостаток
од проверки кои спречуваат да се користат голем броj (или бесконечно) ресурси сеуште претставу-
ваат проблем во развоjот на Linux кернелот. Со оглед на тоа што самиот кернел не е првично
дизаjниран со акцент на безбедност, проблемот станува потежок бидеj´ки е покомплицирано да се
пронаjде решение кое ´ке ги реши постоечките безбедносни проблеми, но и ´ке биде компатибилно
со системите и апликациите кои го користат, без да предизвика дополнителни проблеми.
Со текот на времето, одредени безбедносни проблеми, како што е неправилна употреба на set-
UID и set-GID битовите, постепено се редуцирани, но кернелот сеуште се соочува со одредени
безбедносни пропусти за кои нема унифициран пристап на решавање. Овие карактеристики
потекнуваат од основниот UNIX безбедносен модел - Discretionary Access Control (DAC) [2], коj
е имплементиран во Linux. DAC е едноставен и ефективен метод, но не е соодветен за модерни
средини бидеj´ки не заштитува од небезбеден код, и не покрива одредени ресурси, како што се
пакетни текови. Еден од основните принципи при развоj на нови безбедносни карактеристики во
Linux кернелот е што не смее да се попречи функционирањето на постоечките апликации, што
ги ограничува можностите за развоj на напредни безбедносни механизми. Поради овие причини,
инициjалните безбедносни механизми се базираат на постоечките DAC карактеристики. Една од
нив е POSIX Access Control Lists (ACL) - листи за пристап кои ги прошируваат постоечките DAC
листи за пристап во однос на грануларност, овозможуваj´ки посебни пермисии за индивидуални
корисници и различни групи. Овие листи за пристап се менаџираат на диск со проширени
атрибути кои содржат метаподатоци за датотеките. Друга карактеристика се POSIX Capabilities
3
5. чиjа цел е да се редуцира мо´кта на суперкорисникот, така што кога на одредена апликациjа и
се потребни привилегии, ´ке ги добие само оние привилегии што и се потребни за да jа изврши
задачата. Пример е CAP_MAC_ADMIN способноста коjа му овозможува на процесот привилегии за
извршување на мрежни операции, како што е конфигурациjа на интерфеjси, модификациjа на
рутирачки табели и администрациjа на огнени ѕидови. Дел од овие привилегии не се доволно
грануларни и му овозможуваат на процесот пове´ке привилегии од што реално му се потребни.
Доколку напа´гач компромитира процес со одредена привилегиjа, се стекнува со истите привилегии
со кои располага процесот.
Namespaces (именски простори) се карактеристики кои изолираат и виртуелизираат ресурси
за процесите во системот, така што ресурсите на еден процес не се пристапни за друг. Често се
имплементираат со помош на Pluggable Authentication Modules (PAM).
Во однос на мрежна безбедност, Linux иплементира системи како што е Netfilter. Netfilter е
рамка за филтрирање пакети коjа е имплементирана во Linux кернелот и игра многу важна
улога во безбедноста на Linux бидеj´ки Linux системи често се користат како jазли во мрежа,
со што има потреба од анализа на сите протоколи кои ги поддржува и користи системот. Net-
filter функционира на IP ниво и ги анализира сите пакети кои пристигнуваат и го напуштаат
системот. Кернел модули можат да се закачат за оваа рамка за да jа анализираат содржината
на пакетите кои поминуваат низ системот. Еден од нив е iptables модулот коj се конфигурира од
userland (корисничкиот простор), со помош на IPv4 листи за пристап, и ip6tables за IPv6. Слично,
ebtables овозможува филтрирање на линк ниво, а arptables нуди филтрирање на ARP пакети.
Дополнително, мрежниот стек содржи и имплементациjа на IPsec што се користи за заштита
на IP комуникации со имплементациjа на виртуелна приватна мрежа (VPN) или точка-до-точка
безбедност (point-to-point security).
Криптографското API е исто така неизбежна компонента од безбедносната архитектура на
Linux кернелот и се употребува од страна на подсистемите, како што е IPsec имплементациjата.
Linux Security Modules (LSM) API им овозможува на корисниците да се регистрираат и да
добиваат callback за одредни информации поврзани со безбедноста, слично на Netfilter.
Security Enhanced Linux (SELinux) е имплементациjа на грануларна контрола на пристап
конфигурирана од администратор, и заштитува од одредени userland напади базирани на софтвер-
ски грешки и погрешни конфигурации. Покраj овие безбедносни механизми, постоjат и ред други
имплементирани во различни дистрибуции, но не се во можност да нудат целосна заштита од
напади на кернелот.
Во однос на безбедност на мемориjата, Linux имплементира механизми како што е Address
Space Layout Randomization (ASLR) и NX (No eXecute) битот коj е често поддржан хардверски
или преку емулациjа. ASLR сместува одредени мемориски региони на кориснички процеси на
случаjни локации што спречува напади кои таргетираат специфични мемориски адреси. Оваа
техника е прилично успешна во системи кои генерираат пове´ке ентропиjа, со што напа´гачот
има потешкотии да ги погоди мемориските адреси кои му овозможуваат да го контролира текот
на извршување, но во одредени случаеви е лесно да се заобиколи со внесување на NOP Sled
- низа од NOP (No oPeration) инструкции кои го лизгаат текот на извршување до краjот на
низата каде се нао´га наjчесто jump инструкциjа што го пренасочува текот на извршување по
желба на напа´гачот. NX битот се користи за да се раздели мемориjата коjа содрши извршни
инструкции од мемориjата коjа чува податоци. Оперативниот систем означува одредени области
од мемориjата како неизвршни, со што процесорот ´ке одбие да изврши код коj се нао´га во овие
мемориски региони. Успехот на напа´гачот коj експлоатира ранливости во Linux кернелот зависи
од имплементациjа на горенаведените заштитни мерки, но и од површината за напад коjа му
овозможува да искористи различни вектори за напад. Поради овие причини, имплементациjа
на заштитни мерки не е доволна за одбрана од напа´гачи, особено кога станува збор за одбрана
од напади кои може да се злоупотребат преку мрежа (remote exploits). Ранливости што можат
4
6. да се злоупотребат од оддалечен напа´гач претставуваат поголем ризик од локални ранливости
бидеj´ки се полесни за експлоатациjа.
1.1 Мотивациjа и цел на истражувањето
Ова истражување ги опфа´ка мрежните ранливости кои се нао´гаат во Linux кернелот и можат
да се злоупотребат од оддалечен напа´гач, без локален пристап на системот. Оддалечена експлоата-
циjа на кернелот има предност што резултира со root привилегии, за разлика од оддалечена
експлоатациjа во кориснички простор каде се во функциjа заштитните мерки на кернелот и често
резултираат со редуцирани привилегии. Од друга страна, неуспешна оддалечена експлоатациjа
во кернелот резултира со пад на целиот оперативен систем, додека неуспешна оддалечена експлоа-
тациjа во кориснички простор резултира само со пад на процесот или сервисот коj бил предмет
на експлоатациjа. Целта е да се идентификуваат наjранливите подсистеми, функциите кои
содржат наjмногу ранливости, но и класите на ранливости кои се наjприсутни во Linux кернелот.
Истражувањето ги опфа´ка мрежните ранливости во Linux кернелот во периодот од 2004 до 2016
година - 192 на броj. Податоците се собрани со помош на Python скрипта коjа парсира CVE
(Common Vulnerabilities and Exposures) идентификатори од nvd.nist.gov базата (National Vulner-
ability Database) и се класифицирани во однос на подсистемот во коj се нао´гаат, годината во
коjа се пронаjдени, влиjанието што го имаат, CWE (Common Weaknesses Enumeration) класата
и CVSS (Common Vulnerability Scoring System) оценката за проценка на ризик.
1.2 Слични истражувања
Концептот на оддалечена експлоатациjа во кернел прв го претставува Barnaby Jack на Black
Hat USA конференциjата во 2005 година со неговата презентациjа Remote Windows Kernel Ex-
ploitation: Step into the Ring 0 [3]. После него, други истражувачи, како што се Alfredo Ortega
и Gerardo Richarte почнаа да развиваат различни техники за експлоатациjа на кернелот и во
2007 година jа обjавиjа првата ранливост предизвикана од претекување на heap структурата
во OpenBSD кернелот во IPv6 имплементациjата [4]. Dan Rosenberg, како еден од наjдобрите
истражувачи во полето на безбедноста на Linux кернелот, во 2011 jа обjавува своjата презентациjа
Anatomy of a Remote Kernel Exploit [5] со детална процедура за развивање на код за оддалечена
злоупотреба на Linux кернелот со помош на ранливост во ROSE протоколот. Други истражувачи,
ме´гу кои и Jeff Vander Stoep во 2016, се занимаваат со други оперативни системи кои го користат
Linux кернелот, како што е Android [6]. Во однос на заштита, Serguei A. Mokhov, Marc-Andr´e
Laverdi`ere и Djamel Benredjem со своето истражување Taxonomy of Linux Kernel Vulnerability
Solutions [7] ги анализираат заштитните мерки против наjчестите ранливости во Linux кернелот,
како и Haogang Chen, Yandong Mao, Xi Wang, Dong Zhou, Nickolai Zeldovich и M.Frans Kaashoek
со истражувањето Linux kernel vulnerabilities: State-of-the-art defenses and open problems [8].
5
7. Глава 2
Стандарди за ранливости
2.1 Common Vulnerabilities and Exposures (CVE)
CVE [9] е речник од имиња за jавно познати безбедносни ранливости. CVE системот се
користи за референцирање на jавно познати безбедносни ранливости. Системот е одржуван од
страна на National Cybersecurity FFRDC, под MITRE корпорациjата. Документациjата дефинира
CVE идентификатори, исто познати како CVE имиња и CVE броеви, кои се уникатни за jавно
познатите ранливости. Во минатото, CVE идентификаторите имаа статус на кандидати со префикс
CAN- и потоа можеа да бидат унапредени во CVE, ме´гутоа кандидатски идентификатори пове´ке
не се користат и сите идентификатори се стандардно CVE. CVE идентификатори се доделуваат
од CVE Numbering Authority (CNA), како што се:
1. MITRE Corporation функции како едитори и примарни CNA.
2. Одредени CNA доделуваат CVE идентификатори за своите продукти, како што се Mi-
crosoft, Oracle, HP, Red Hat, и сл.
3. Трета страна координатор како што е CERT координациски центар може да додели CVE
идентификатор на продукти што не се покриени од други CNA.
При истражување на ранливости или потенциjални ранливости, CVE идентификаторот помага
во процедурата. Причината зошто CVE системот помага е бидеj´ки во минатото, ранливостите
во продукти добивале различни идентификатори и поради овие разлики, тешко било да се
процени кога различни бази со ранливости референцираат една иста ранливост. Последиците
биле потенциjални дупки во покриеност на безбедносни дупки и недостаток од ефективна интеро-
перабилност поме´гу различни бази со ранливости и алатки. Секоj производител користел различна
метрика за да го обjави броjот на ранливости или слабости кои ги пронашле, без стандарди за
евалуациjа. CVE идентификаторите може да не се поjават во MITRE или NVD CVE базите
одредено време поради проблеми и пречки, или во случаеви кога ранливоста не е доволно
инстражена. CVE идентификатори се доделуваат само за софтвер што е jавно обjавен, вклучител-
но со бета верзии и други верзии кои се во широка употреба. Софтвер што не е jавно достапен
не добива CVE. Дополнително, сервиси не добиваат CVE за ранливости во сервисот, освен ако
ранливоста постои во софтверски продукт коj е jавно достапен и го имплементира тоj сервис.
Во секоjа база на ранливости, има неколку полиња што се секогаш присутни:
• Опис: стандардизиран текстуален опис на проблемот. Пред да се обjават jавно деталите
од ранливоста, ова поле се обележува како резервирано до моментот кога ´ке се обjават
информациите jавно. Некои CNA побаруваат блокови од CVE идентификатори однапред,
со што истите се обележуваат како резервирани, иако можеби сеуште не се искористени за
одредена ранливост. Овие описи се обележани со ** RESERVED **.
• Референци: листа од URLа и други информации за проблемот.
6
8. • Датум на записот: датумот кога е креиран записот. За CVE доделени од MITRE, датумот
соодветствува со тоj кога записот бил креиран. За записи доделени од CNA, датумот е
истиот кога записот е исто така креиран од MITRE, не од CNA.
Форматот на CVE идентификатори до 1 Jануари 2014 година беше CVE-YYYY-NNNN, каде
YYYY jа претставува годината во коjа е пронаjдена ранливоста, а NNNN е секвентен броj коj
се инкрементира за секоjа последователна ранливост за коjа е доделен CVE ID. Денес CVE
идентификаторите може да имаат четири или пове´ке цифри во секвентниот броj на идентифика-
торот, така што може да се користат идентификатори во формат CVE-YYYY-NNNNN и CVE-
YYYY-NNNNNN со цел да може да се доделат пове´ке од 9999 идентификатори годишно. Секоj
CVE запис во National Vulnerability Database (NVD), покраj основните CVE информации, има и
информации околу влиjанието на ранливоста и ризиците. На пример, ранливоста CVE-2015-1465
[10] е пронаjдена во 2015 година, што може да се види од самиот идентификатор на ранливоста.
NVD записот ги содржи сите потребни информации што ги опишуваат ризиците и векторите за
напад.
2.2 Common Vulnerability Scoring System (CVSS)
CVSS [11] е бесплатен и отворен индустриски стандард за проценка на сериозноста на ранливос-
тите. Одржуван е од страна на Forum of Incident Response and Security Teams (FIRST), чиjа цел
е да им помогне на тимовите за одговор на компjутерски инциденти. CVSS доделува оценки
за сериозноста, со цел да помогне во приоретизирање на одговор и распределба на ресурси за
санирање на заканите. Оценката се пресметува со помош на формула коjа зависи од неколку
метрики што земаат во предвид параметри како што се едноставност на експлоатациjа и импакт
на злоупотребата.
CVSS се состои од три метрички групи: базни, временски и околински, прикажано на слика
2.1 Базната група ги претставува внатрешните квалитети на ранливоста, временската група ги
рефлектира карактеристиките на ранливост коjа се менува со текот на времето, и околинската
група ги претставува карактеристиките на ранливоста што се уникатни за средината на корисни-
кот. Базните метрики резултираат со оценка од 0 до 10, каде што 10 претставува сериозна
ранливост. Оваа оценка може да се модифицира со помош на временските и околинските метрики.
CVSS оценката исто така се претставува како векторска низа коjа е комперсирана верзиjа од
вредностите што се користат за изведување на оценката. Моменталната верзиjа на CVSS е v3,
ме´гутоа дел од CVE записите кои се опфатени во ова истражување немаат CVSSv3 оценка,
поради што само CVSSv2 оценките се земени во предвид. Главните промени во CVSSv3 се
однесуваат на ранливости во веб апликации, кои со новиот систем добиваат попрецизна проценка
на ризиците со помош на додатни метрики. Сите CVE записи во NVD базата содржат информации
за CVSSv2 базната оценка, но моментално не содржат информации за временските и околинските
оценки.
CVSSv2 базните метрики вклучуваат шест параметри, од кои три се однесуваат на оценката
на злоупотребливост:
• Access Vector (AV) - рефлектира како ранливоста се злоупотребува. Возможни вредности
за оваа метрика се Local (L) - напа´гачот може да jа злоупотреби ранливоста локално; Adja-
cent Network (A) - напа´гачот може да jа злоупотреби ранливоста во локален или колизиски
домен; Network (N) - напа´гачот може да jа злоупотреби ранливоста преку оддалечена
мрежа.
• Access Complexity (AC) - оваа метрика jа мери комплексноста на нападот откако напа´га-
чот ´ке доjде во контакт со системот. Возможни вредности се High (H) - потребни се
специjализирани услови за експлоатациjа; Medium (M) - пристапните услови имаат делумни
ограничувања; Low (L) - не се потребни специjализирани услови.
7
9. Слика 2.1: CVSSv2 метрички групи.
• Authentication (Au) - мери колку пати е потребно напа´гачот да се автентицира на
системот со цел да jа експлоатира ранливоста. Возможни вредности се Multiple (M) -
напа´гачот е потребно да се автентицира два или пове´ке пати на системот; Single (S) -
потребно е напа´гачот еднаш да се автентицира на системот; None (N) - не е потребна
автентикациjа за злоупотреба.
Останатите три метрики се однесуваат на влиjанието на ранливоста:
• Confidentiality Impact (C) - оваа метрика го мери влиjанието на доверливоста при
успешна експлоатациjа. Возможни вредности се None (N) - нема влиjание на доверливоста;
Partial (P) - има делумно откривање на информации или пристап до одредени датотеки;
Complete (C) - целосно откривање на информации и пристап до сите податоци во системот.
• Integrity Impact (I) - влиjание врз интегритетот при успешна експлоатациjа. Возможни
вредности се None (N) - интегритетот не е загрозен; Partial (P) - возможна е модификациjа
врз дел од податоците од системот; Complete (C) - интегритетот на системот е целосно
компромитиран и напа´гачот може да ги модифицира сите податоци.
• Availability Impact (A) - влиjание на достапноста на системот при успешна експлоатациjа.
Возможни вредности се None (N) - нема влиjание врз достапноста на системот; Partial
(P) - редуцирани перформанси или прекини во достапноста на ресурсот; Complete (C) -
компромитираниот ресурс е целосно недостапен.
Краjната базна оценка на ранливоста се изведува со помош на горенаведените метрики. На
пример, ранливоста CVE-2015-1465 во NVD базата е со CVSSv2 базна оценка 7.8, што jа става во
групата на високо-ризични ранливости. Векторот на ранливоста е AV:N/AC:L/Au:N/C:N/I:N/A:C,
што укажува дека ранливоста може да се злоупотреби од оддалечена мрежа, нападот е со ниска
комплексност, не е потребна автентикациjа, нема влиjание врз доверливоста и интегритетот, но
целосно jа оневозможува достапноста на системот. Оценката за влиjание е 6.9, додека оценката
за злоупотребливост е 10.
8
10. 2.3 Common Weaknesses Enumeration (CWE)
Скоро секоjа ранливост во NVD базата има доделен CWE идентификатор коj jа определува
класата на слабости. CWE [12] е:
• Формална листа од типови на софтверски слабости коjа се користи за да се опишат софтвер-
ски ранливости во архитектура, дизаjн или код.
• Стандард за мерење на безбедносни алатки кои ги таргетираат овие ранливости.
• Како заеднички основен стандард за идентификациjа на ранливости, и начини за справување
и намалување на ризиците.
Проектот е спонзориран од страна на National Cybersecurity FFRDC под сопственост на MITRE
корпорациjата. MITRE работи на категоризациjа на ранливости од 1999, почнуваj´ки со CVE
(Common Vulnerabilities and Exposures) листата. Како дел од развоjот на CVE, MITRE развива
прелиминарна класификациjа и категоризациjа на ранливости, напади, грешки и други концепти
за полесно да се дефинираат софтверски слабости, коjа со тек на време еволуира во денешната
CWE листа и класификациско дрво кои служат како механизам за опишување на можности
за проценка на код во однос на покриеност на различни CWE класи. CWE листата е постоjано
надградувана со нови класификации и категории кои помагаат за прецизна проценка на ризикот
од одредена слабост, како може таа слабост да се трансформира во ранливост во системот и
техниките за намалување на истиот. CWE категориите се во форма на дрво, каде една категориjа
има пове´ке деца категории кои споделуваат заеднички карактеристики.
Во однос на CWE категориjата, ранливостите кои влегуваат во опсегот на ова истражување
спа´гаат во една од следните категории:
• CWE-399 - Resource Management Errors: опфа´ка ранливости кои се поврзани со
несоодветно менаџирање на системски ресурси од страна на кернелот. Во оваа категориjа
спа´гаат грешки како што се: неконтролирано трошење на ресурси, протекување на мемориjа,
недоволна алокациjа на ресурси, користење на мемориjа по ослободување, дереференцирање
на невалиден покажувач и сл.
• CWE-119 - Improper Restriction of Operations within the Bounds of a Memo-
ry Buffer: софтверот извршува операции на мемориски бафер, но може да чита или да
запишува во мемориски локации надвор од предвидените граници на баферот. Одредени
jазици, како што се C и C++, дозволуваат директно адресирање на мемориски локации и не
вршат автоматски проверски дали овие локации се валидни за меморискиот бафер што се
референцира. Ова овозможува на напа´гач да изврши операции за читање или запишување
на мемориски локации што се асоцирани со други променливи, податочни структури или
внатрешни програмски податоци. Како резултат, напа´гач може да изврши произволен код,
да го измени текот на извршување, да чита осетливи информации или да предизвика пад на
системот. Друго име за оваа класа на слабости е корупциjа на мемориjа. Слабости во оваа
категориjа се класично претекување на баферот, читање и запишување надвор од граници,
несоодветно справување со параметар за должина, повратна вредност на покажувач надвор
од очекуван опсег, пристап до мемориска локациjа пред почетокот на баферот, пристап до
неинициjализиран покажувач, и сл.
• CWE-20 - Improper Input Validation: софтверот не валидира или неточно валидира
влез што може да влиjае на контролниот или податочниот тек на програмата. Напа´гач може
да внесе влез во форма што не е очекувана од апликациjата, со што делови на системот ´ке
примат невалиден влез што може да резултира со изменет тек на извршување, произволна
контрола на ресурс или произволно извршување код. Овоj проблем може да се поjави во
секоj програмски jазик и зависи од контролите што ги има поставено програмерот. Во оваа
категориjа спа´гаат претежно веб апликациски ранливости, како што се SQL инjекциjа и
Cross-site scripting, но вклучува и ранливости кои го афектираат кернелот, како што се
9
11. контрола на подесувања, несоодветно валидирање на индекс на низи, NULL покажувач
дереференцирање, претекување на цел броj, и сл.
• CWE-189 - Numeric Errors: се jавуваат како резултат на несоодветни пресметки или
конверзии на броеви. Често резултираат со алокациjа на поголем броj на мемориски локации
во бафер кои можат да бидат искористени од напа´гач. Тука спа´гаат слабости како што се
несоодветна валидациjа на индекс на низи, претекување и подтекување на баферот, неточни
пресметки, неточна конверзиjа поме´гу нумерички типови и сл.
• CWE-362 - Concurrent Execution using Shared Resource with Improper Syn-
chronization (’Race Condition’): слабости кои настануваат кога програмата содржи
кодна секвенца коjа работи конкурентно со друг код, и на кодната секвенца и е потребен
привремен, ексклузивен пристап до споделен ресурс, но постои временски прозорец во
коj споделениот ресурс се модифицира од друга кодна секвенца коjа работи конкурентно.
Безбедносни импликации има кога синхронизациjата е во безбедносно-критичен сегмент,
како што е проверки дали корисникот е автентициран или модификациjа на важни состоjбе-
ни информации. Програмерите често претпоставуваат дека одредени кодни секвенци се
извршуваат премногу брзо за да бидат афектирани од друга кодна секвенца. Пример за
ваква операциjа е x++ операциjата коjа во кодот можеби изгледа атомично, но е всушност
неатомична бидеj´ки вклучува три операции - читање на оригиналната вредност на x,
пресметка x+1 и запишување на резултатот во x. Примери се справувачите со сигнали
кои можат да доjдат до ваква состоjба, трка во нишки, Time-of-check Time-of-use трка,
трка во промена на контекст и сл.
• CWE-200 - Information Exposure: намерно или ненамерно откривање на информации
кои не треба да бидат достапни. Информациjата може да биде осетлива во зависност
од функционалноста на програмот, како што се приватни пораки во апликациjа, или да
открива информации за апликациjата или средината што може да се искористат во усовршу-
вање на поуспешен напад, како што е инсталациски пат на апликациjа. Во оваа категориjа
спа´гаат слабости како што се изложување на информации преку испратени податоци,
изложување на информации преку пораки за грешки, намерно откривање податоци, и сл.
• CWE-264 - Permissions, Privileges, and Access Controls: слабости кои се поврзани
со менаџирање на пермисии, привилегии и други безбедносни мерки кои се користат за
спроведување контрола на пристап. Вклучува слабости во однос на несоодветно менаџирање
на сопственост на ресурси, несоодветна контрола на пристап, и сл.
Останатите CWE категории вклучуваат конфигурациски слабости, криптографски слабости,
автентикациски слабости и друго. Дел од ранливостите немаат доделен CWE идентификатор,
бидеj´ки нема доволно информации околу слабоста или бидеj´ки ранливоста вклучува експлоатациjа
на пове´ке класи на слабости.
10
12. Глава 3
Детали од истражувањето
3.1 Методологиjа
Во истражувањето влегуваат 192 ранливости со доделени CVE идентификатори. Податоците
се собрани со помош на Python скрипта коjа со Xpath изрази ги собира релевантните податоци
за секоj CVE идентификатор соодветно од NVD базата. Треба да се напомене дека некои CVE
идентификатори со еден запис опфа´каат две или пове´ке софтверски грешки кои индивидуално
или заедно можат да се злоупотребат од напа´гач. Бидеj´ки целта е да се идентификуваат наjранли-
вите подсистеми во кернелот, како и класите на ранливости кои се наjзастапени, секоj CVE запис
е независно анализиран.
Некои CVE записи не содржат целосни податоци за техничките детали на ранливоста, но
направена е наjприближна проценка во однос на подсистемите кои би биле наjвероjатно опфатени
од истата. Некои CVE записи во NVD базата содржат информациjа дека имаат мрежен вектор
за напад (Access Vector: Network или Adjacent Network), но всушност напа´гачот мора да има
локален пристап на системот за да ги злоупотреби. Овие ранливости не се опфатени во истражува-
њето, туку само оние ранливости кои вистински можат да се злоупотребат од оддалечен напа´гач,
пример преку испра´кање на специjално изградени пакети кои предизвикуваат софтверски грешки
на страната на примачот. Земени се во предвид ранливости кои се од 2004 година - поточно
ранливости во кернелите од верзиjа 2.6, до 2016 верзиjа 4.8, кои имаат 3+ базна оценка по
CVSSv2.
Извршена е анализа на дистрибуциjата на ранливостите низ годините со цел да се утврди дали
новите подсистеми кои се имплементираат се дизаjнираат со безбедност во предвид и дали тоа
влиjае на броjот на ранливости годишно. Полиња од интерес се CVSSv2 оценката, тип на влиjание
(Impact Type) и CWE идентификатор. Со оглед на тоа што CVE записите не содржат технички
информации за функциите и подсистемите кои ги опфа´ка ранливоста, направена е анализа на
секоjа ранливост со цел да се добие статистика за броjот на ранливости по подсистем.
3.2 Резултати
3.2.1 Дистрибуциjа на ранливости
Од сите 192 ранливости кои можат да се злоупотребат од оддалечена мрежа, како што може да
се види на слика 3.1, 126 (65.62%) се нао´гаат во мрежниот стек на кернелот - net/ , 32 (16.66%)
се во подсистемот за драjвери - drivers/, 21 (10.93%) во подсистемот на податочните системи -
fs/ , 3 (1.56%) во include подсистемот - include/ , а останатите 10 (5.20%) ранливости спа´гаат
во некоj друг подсистем или нема доволно информации за соодветно да се категоризираат. Од
11
13. 65.62%
16.66%
10.93%
1.56%
5.20%
net/
drivers/
fs/
include/
Other
Слика 3.1: Дистрибуциjа на ранливости во подсистемите.
126 ранливости во мрежниот стек, прикажано на слика 3.2, наjголем броj ранливости содржи
net/ipv4 - 28 (22.22%). Во овоj подсистем карактеристични се Netfilter кодот коj е задолжен
за пакетна анализа во кернелот со 6 ранливости, tcp_input.c со 5, ICMP имплементациjата со
3 и механизмот за фрагментациjа со 3. Втор е Stream Control Transmission Protocol (SCTP)
- net/sctp подсистемот со вкупно 24 (19.04%) ранливости. Посебно ранливи се датотеките
associola.c, sm_make_chunk.c и sm_statefuns.c со по 4 ранливости во секоjа, и input.c со 3
ранливости. Трет по броjност е net/ipv6 подсистемот со 19 (15.07%) ранливости. Иако ранливос-
тите се претежно дистрибуирани низ различните датотеки, карактеристични се exthdrs.c со
Jumbo frame функционалноста во IPv6 со 3 ранливости и addrconf.c со 2 ранливости. Netfilter -
net/netfilter подсистемот содржи 12 (9.52%) ранливости, каде 6 се во conntrack функционал-
носта за следење на состоjба на конекции, од кои 3 се во nf_conntrack_proto_sctp.c. 7 (5.55%)
ранливости има во jадрото на мрежниот подсистем - net/core кои се дистрибуирани низ различни
датотеки, од кои 2 се во sock.c.
22.22%
19.04%
15.07%
9.52%
5.55%
3.17%3.17%2.38%2.38%2.38%
1.58%1.58%
1.58%
1.58%
1.58%
7.14%
net/ipv4
net/sctp
net/ipv6
net/netfilter
net/core
net/ceph
net/rose
net/dccp
net/mac80211
net/8021q
net/x25
net/econet
net/wireless
net/batman_adv
net/bridge
Other
Слика 3.2: Дистрибуциjа на ранливости во net/ подсистемот.
12
14. Останатите ранливости се дистрибуирани низ различни подсистеми, како што се Remote Op-
erations Service Element (ROSE) протоколот - net/rose и Ceph имплементациjата во net/ceph,
двата со по 4 (3.17%) ранливости. Во Ceph имплементациjата, 3 ранливости се во auth_x.c
датотеката коjа се справува со автентикациjа. Следуваат net/dccp, net/mac80211 и net/8021q со
по 3 (2.38%) ранливости поединечно. Со по 2 (1.58%) ранливости се net/x25 во x25_facilities.c,
net/econet во af_econet.c, net/wireless во scan.c, net/batman_adv и net/bridge. Останатите
ранливости се во другите подсистеми во net/ и сочинуваат 7.14% од вкупниот броj на ранливости
во мрежниот стек.
Од 192 ранливости, прикажано на слика 3.3, 32 (16.66%) се во драjверите - претежно драjвери
што се задолжени за справување со мрежен сообра´каj. Од вкупно 32 ранливости, 19 (59.37%)
се во drivers/net од кои 6 се во имплементациjата за безжична комуникациjа, и по 3 во
e1000_main.c и r8169.c. 4 (12.5%) ранливости се во drivers/staging/ozwpan. Со по 2 (6.25%)
ранливости се подсистемите drivers/infiniband во cma.c, drivers/media/dvb во dvb_net.c и
drivers/usb. Останатите 3 ранливости се нао´гаат во други подсистеми под drivers/ .
59.37%
12.5%
6.25%6.25%
6.25%
9.37%
drivers/net
drivers/staging/ozwpan
drivers/infiniband
drivers/media/dvb
drivers/usb
Other
Слика 3.3: Дистрибуциjа на ранливости во drivers/ подсистемот.
Во однос на ранливостите во податочните системи во Linux, прикажано на слика 3.4, 21
(10.93%) ранливост, од вкупно 192, се во fs/ подсистемот. Мнозинството се во Common Internet
File System (CIFS) - fs/cifs имплементациjата, поточно 7 (33.33%), од кои 3 се во cifssmb.c,
2 во connect.c. На второ место е Network File System (NFS) имплементациjата, каде 5 (23.80%)
се во серверската имплементациjа на NFS лоцирана во fs/nfsd.c, од кои 2 во nfs4acl.c, а 4
(19.04%) се во имплементациjата на клиентот во fs/nfs, од кои 2 се во nfs4proc.c. Со по 2
(9.52%) ранливости се fs/lockd и fs/smbfs, додека една ранливост се нао´га во друг подсистем
под fs/.
Во include/ има 3 (1.56%) ранливости, од кои 2 (66.66%) се во include/linux во netdevice.h.
Останатите 10 (5.20%) ранливости се претежно дистрибуирани низ другите подсистеми кои не
се под net/, drivers/, include/ или fs/.
13
15. 33.33%
23.80%
19.04%
9.52%
9.52%
4.76%
fs/cifs
fs/nfsd.c
fs/nfs
fs/lockd
fs/smbfs
Other
Слика 3.4: Дистрибуциjа на ранливости во drivers/ подсистемот.
Сите ранливости кои влегуваат во истражувањето се пронаjдени од 2004 до 2016 и нивната
дистрибуциjа е прикажана на слика 3.5. Во 2004 биле приjавени 5 ранливости, во 2005 13
ранливости, во 2006 19 ранливости, во 2007 10 ранливости, во 2008 11 ранливости, во 2009 и
во 2010 по 20 ранливости, во 2011 32 ранливости, во 2012 10 ранливости, во 2012 13 ранливости,
во 2013 13 ранливости, во 2014 22 ранливости, во 2015 12 ранливости и во 2016 5 ранливости, до
моментот на истражувањето.
2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
0
10
20
30
Year
Numberofvulnerabilities
Слика 3.5: Дистрибуциjа на ранливости по година.
3.2.2 CVSSv2 базни оценки
CVSSv2 базните оценки на слика 3.6 покажуваат дека мнозинството од ранливостите, поточно
98 (51.04%), имаат оценка 7.0 - 7.9 што спа´га во опсегот на високо-ризични ранливости. Потоа
следуваат ранливостите со оценки 5.0 - 5.9 со 47 (24.47%), кои спа´гаат во средно-ризични
ранливости. Со оценка 6.0 - 6.9 се 15 (7.81%) од ранливостите кои исто така спа´гаат во категориjа
на средно-ризични ранливости. На четврто место се ранливостите со оценка 10.0, со вкупно
13 (6.77%) ранливости кои спа´гаат во категориjа на критични ранливости. Со оценки 9.0 -
9.9 и 4.0 - 4.9 се по 6 (3.12%) ранливости поединечно, кои спа´гаат во групата на критични и
средно-сериозни ранливости соодветно. Со оценка 3.0 - 3.9 се вкупно 4 (2.08%) ниско-ризични
ранливости. Преостанатите 3 (1.56%) ранливости се со оценка 8.0 - 8.9, рангирани како високо-
14
16. ризични.
2.08%
3.12%
24.47%
7.81%
51.04%
1.56%
3.12%
6.77%
3.0 - 3.9
4.0 - 4.9
5.0 - 5.9
6.0 - 6.9
7.0 - 7.9
8.0 - 8.9
9.0 - 9.9
10.0
Слика 3.6: Дистрибуциjа на CVSSv2 базни оценки.
3.2.3 CWE класи
Иако не е совршено прецизна, CWE класата на слабости укажува коj тип на ранливости е
наjзастапен. Бидеj´ки CWE класификациjата е креирана ве´ке откако CVE идентификаторите се
во широка употреба, дел од CVE записите во NVD не содржат информациjа за CWE класата на
слабост, претежно записите од 2004 и 2005 година, но и неколку понови. Делумно, недостаток
од класификациjа се должи и на фактот дека некои CVE идентификатори покриваат две или
пове´ке ранливости кои би можеле да влезат во пове´ке класификации, или нема доволно технички
информации за ранливоста.
Покраj CWE класата, NVD содржи и информации за типот на влиjание кое ранливоста го има
врз нападнатиот систем. Една ранливост може да има пове´ке различни типови на влиjание врз
системот, како што се овозможуваj´ки на напа´гач да открие осетливи информации за системот
и притоа да му овозможува да го прекине нормалното функционирање на сервисот. Прикажано
во табела 3.1, наjголем броj на ранливости резултираат со прекин на сервисот, поточно од 192
ранливости 176 му овозможуваат на напа´гач да предизвика прекин во работата на системот. 50
овозможуваат откривање на осетливи информации за системот. 31 ранливост му дозволуваат
на напа´гач да изменува податоци во системот, нарушуваj´ки го интегритетот. 3 ранливости
резултираат со администраторски пристап и целосно нарушување на доверливоста, интегритетот
и пристапноста, додека 4 ранливости резултираат со кориснички пристап и делумно нарушување
на доверливоста, интегритетот и пристапноста.
Табела 3.1: Броj на ранливости по влиjание.
Allows unauthorized modification 31
Allows disruption of service 175
Allows unauthorized disclosure of information 50
Provides administrator access, Allows complete confidentiality,
integrity, and availability violation
3
Provides user account access, Allows partial confidentiality,
integrity, and availability violation
4
15
17. Според слика 3.7, наjзастапена CWE класа на слабости е Resource Management Errors со 38
(19.79%) ранливости кои припа´гаат во оваа категориjа. Втора по броjност е Buffer Errors со
29 (15.10%) ранливости. Следна е класата Input Validation со 22 (11.45%) ранливости, по коjа
следи Numeric Errors со 21 (10.93%). Race Conditions ранливости се 9 (4.68%), приближно со
Information Leak / Disclosure ранливости кои се 8 (4.16%) на броj. Останатите класи имаат
значително помало присуство, од кои 3 (1.56%) спа´гаат под Permissions, Privileges, and Access
Control, додека Configuration, Cryptographic Issues, Authentication Issues, Code и Other имаат по
2 (1.04%) ранливости од секоjа класа. На последно место е Security Features класата, од коjа има
само 1 (0.52%) ранливост. Останатите 51 (26.56%) ранливости немаат CWE идентификатор за
класа на слабост од причина што нема доволно информации или едноставно не им бил доделен
при формирање на записот.
19.79%
15.10%
11.45%
10.93%
4.68%
4.16%
1.56%1.04%1.04%1.04%1.04%1.04%0.52%
26.56%
Resource Management Errors
Buffer Errors
Input Validation
Numeric Errors
Race Conditions
Information Leak / Disclosure
Permissions, Privileges, and Access Control
Configuration
Cryptographic Issues
Authentication Issues
Code
Other
Security Features
No CWE
Слика 3.7: Дистрибуциjа на CVSSv2 базни оценки.
3.3 Анализа
Резултатите покажуваат дека во Linux кернелот има неколку подсистеми во кои се сконцентри-
рани мнозинството од ранливостите кои можат да се злоупотребат од оддалечен напа´гач. net/ipv4
подсистемот содржи наjголем броj на ранливости, што е очекувано со оглед на тоа што IPv4
имплементациjата е стара. Во времето кога имплементациjата била првично осмислена, не бил
предвиден проблемот со безбедноста на системите. net/sctp подсистемот е релативно понов, но
комплексноста на протоколот, коj воедно треба да го замени TCP во иднината, прави ранливостите
во овоj подсистем да бидат неизбежни, без разлика што самиот SCTP протокол е дизаjниран со
безбедност во предвид. net/ipv6, исто така релативно нов подсистем, страда од истите проблеми
како SCTP - комплексен неопходен протокол коj е дизаjниран со безбедност во предвид, но
самата имплементациjа не е отпорна на ранливости поради фактот што овоj подсистем треба да
се справува со скоро секоj пакет што влегува во системот. net/netfilter е исто така еден од
покритичните подсистеми коj е одговорен за анализа на сообра´каjот коj влегува и излегува од
системот, со што не е изненадно што и овоj подсистем страда од слични проблеми како и другите
имплементации на мрежни подсистеми. Модерните напади креираат потреба од грануларно
следење на комуникациjа, со што се зголемува површината коjа евентуален напа´гач би можел
да jа злоупотреби.
Мрежните драjвери во drivers/net исто така сносат голема одговорност за адаптациjа на
сообра´каjот при влегување и излегување од системот, со што и овоj подсистем е очекувано да
содржи одреден броj на ранливости.
16
18. Во однос на податочните системи, fs/nfs* и fs/cifs подсистемите претставуваат посебен
ризик бидеj´ки мрежните податочни системи почнуваат да имаат широка примена, но и притоа
страдаат од ранливости како резултат на справувањето со мрежен сообра´каj кое треба да им jа
овозможи нивната карактеристична функционалност.
Без разлика на броjот на ранливости, мнозинството резултираат со прекинување на сервисот
или пад на системот, а само малку овозможуваат на оддалечен напа´гач да изврши произволен
код на системот. Ова се должи на фактот што пове´кето ранливости се резултат на дереференцира-
ње на NULL покажувач. Наjчесто, дереференцирање на NULL покажувач го прекинува работење-
то на системот со сегментациски дефект, освен кога софтверот вклучува и код коj може да се
справи со овие исклучоци. Во одредени ситуации, дереференцирање на NULL покажувач може
да резултира со прескокнување на некои безбедносни проверки, што е покритична ранливост
од прекин на сервис, или да открие информации за програмата кои може да се злоупотребат.
Фактот што мнозинството ранливости се во CWE класи на грешки со менаџирање на ресурси,
валидациjа на влез, грешки со броеви и грешки со бафери често се должи на употребата на
небезбеден jазик, како што е C, коj овозможува поголема брзина на извршување во споредба со
други jазици, но по цена на недостаток на контроли, со што задачата за санирање на несоодветен
влез од корисник останува на програмерот. Проекти со отворен код, како што е Linux кернелот,
секогаш ´ке бидат изложени на овие грешки од причина што е непрактично да се прави темелна
проверка на кодот за безбедносни пропусти пред да биде внесен во главната гранка.
Во однос на CVSS оценка, не изненадува фактот што пове´кето ранливости спа´гаат во опсегот
на средно-ризични ранливости, но фактот што има поголем броj на ранливости со оценка 10
во споредба со ниско-ризични ранливости, покажува дека е неопходно да се воведе построга
контрола во кодот коj е пишуван од страна на припадници на заедницата на отворен код. Броjот
на приjавени ранливости по година варира, со тоа што во периодот од 2009 до 2011 се приjавени
наjголем броj на ранливости. За жал, и покраj тоа што новите системи се имплементираат
со безбедност во предвид, броjот на ранливости не се редуцира со текот на годините. Броjот на
ранливости во 2016 не е комплетен бидеj´ки истражува-њето е извршено пред краjот на годината.
Класичен пример за оддалечена експлоатациjа е ранливоста CVE-2011-1493 коjа Dan Rosen-
berg [5] jа обjаснува во своjата презентациjа Anatomy of a Remote Kernel Exploit. Ранливоста
е во ROSE протоколот каде при размена на пораки за поддржани опции во комуникациjата,
не се врши проверка на вредноста за должина, со што се копираат податоци без да се изврши
проверка на граници, резултираj´ки со преполнување во стекот. Причината е индексна грешка во
низата во rose_parse_national функциjата во net/rose/rose_subr.c. CVSSv2 базната оценка
е 7.5 (високо-ризична) со вектор AV:N/AC:L/Au:N/C:P/I:P/A:P. Ранливоста се нао´га во следниот
код:
l = p[1];
...
else if (*p == FAC_NATIONAL_DIGIS) {
fac_national_digis_received = 1;
facilities->source_ndigis = 0;
facilities->dest_ndigis = 0;
for (pt = p + 2, lg = 0 ; lg < l ; pt += AX25_ADDR_LEN, lg += AX25_ADDR_LEN) {
if (pt[6] & AX25_HBIT)
memcpy(&facilities->dest_digis[facilities->dest_ndigis++], pt, AX25_ADDR_LEN);
else
memcpy(&facilities->source_digis[facilities->source_ndigis++],pt,AX25_ADDR_LEN);
}
}
17
19. Доколку напа´гачот jа модифицира своjата ROSE имплементациjа да испра´ка пакети со преголемо
поле за должина за FAC_NATIONAL_DIGIS, со додадени NOP (No oPeration - 0x90) инструкции,
текот на извршување ´ке продолжи по NOP инструкциите, по што напа´гачот може да постави
други инструкции, како што се jump и call и да го пренасочи повторно текот кон адреса коjа
се нао´га во стекот и да изврши произволен код.
3.4 Заклучок
Linux кернелот во текот на своjата еволуциjа има претрпено многу промени во своjата структура
кои влиjаеле на безбедноста. Старите протоколи од раните денови на интернетот имале многу
безбедносни грешки кои не биле предвидени при имплементациjа, но и поновите протоколи кои
со своjата комплексност носат и зголемен броj на ранливости. Како што напредува кернелот и
му се додаваат нови протоколи и подсистеми, така ´ке се зголемува и површината за напад.
Бидеj´ки оддалечена експлоатациjа претставува еден од посериозните безбедносни проблеми,
потребно е да се обрне посебно внимание на подсистемите кои се задолжени со справување со
мрежен сообра´каj и примаат влезови од корисници. Linux кернелот се употребува се почесто во
наjразлични уреди - од домашни IoT уреди до суперкомпjутери, со што се зголемува и потребата
од безбедни протоколи. Општата состоjба на безбедноста на кернелот не се подобрува, што може
во иднина да доведе до посериозни проблеми во околини каде безбедноста е од критична важност.
Затоа е неопходно секоj корисник и секоj администратор да превземе дополнителни мерки против
оддалечена експлоатациjа, како што се огнени ѕидови и системи за детекциjа на напади, но и
секоj програмер коj работи со осетливи системи да развива код ставаj´ки jа безбедноста на прво
место.
18
20. Библиографиjа
[1] Ritchie, Dennis M. "‘On the Security of UNIX."UNIX Supplementary Documents (1979).
[2] Morris, James. Overview of Linux Kernel Security Features, [Online] www.linux.com (2013)
[3] Jack, Barnaby. "Remote Windows kernel exploitation: Step into the ring 0."Aliso Viejo, Cal.:
eEye Digital Security (2005).
[4] Ortega, Alfredo and Richarte, Gerardo. OpenBSD’s IPv6 mbufs remote kernel buffer overflow,
[Online] www.coresecurity.com (2007)
[5] Rosenberg, Dan. "Anatomy of a remote kernel exploit."Virtual Security Research (2011).
[6] Stoep, Jeff V. "Android: protecting the kernel"Linux Foundation (2016)
[7] Mokhov, Serguei A., Marc-Andr´e Laverdi`ere, and Djamel Benredjem. "Taxonomy of linux ker-
nel vulnerability solutions."Innovative Techniques in Instruction Technology, E-learning, E-
assessment, and Education. Springer Netherlands (2008)
[8] Chen, Haogang, et al. "Linux kernel vulnerabilities: State-of-the-art defenses and open prob-
lems."Proceedings of the Second Asia-Pacific Workshop on Systems. ACM (2011).
[9] MITRE Corporation. About CVE [Online] cve.mitre.org (2016)
[10] National Vulnerability Database. Vulnerability Summary for CVE-2015-1465 [Online]
web.nvd.nist.gov (2015)
[11] Forum of Incident Response and Security Teams. Common Vulnerability Scoring System [Online]
www.first.org (2015)
[12] MITRE Corporation. About CWE [Online] cwe.mitre.org (2014)
19