DOCSLIB.ORG

Control-Flow Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Control-Flow Security Control-Flow Security by William Patrick Arthur A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Science and Engineering) in The University of Michigan 2016 Doctoral Committee: Professor Todd M. Austin, Chair Associate Professor Prabal Dutta Professor Scott Mahlke Assistant Professor Jason Mars Professor Dennis M. Sylvester c William Patrick Arthur All Rights Reserved 2016 For Allison and Marshall. ii Acknowledgments I would like to first thank my advisor Professor Todd Austin. This work would not be possible without his support and efforts. Serving as a role model, he was always personally motivating and made the work not only possible but a joy. I also thank my committee members for their insight and encouragement; Professors Scott Mahlke, Dennis Sylvester, Prabal Dutta, and Jason Mars. They have proven to be mentors who exemplify what is most admirable about academia and research. Additionally, I thank Reetuparna Das, a person of great importance to this work. Thank you for challenging me to strive for excellence. This work was not completed without the contribution and assistance of others, most notably from my collaborators. My undergraduate collaborators Ben Mehne and Sahil Madeka have proven invaluable. Additionally, my peers in graduate studies have provided invaluable insight and I am ever thankful for their time listening, challenging, and debating my ideas and this work. This includes Salessawi Ferede Yitbarek, Joseph Greathouse, Jason Clemons, Ricardo Rodriguez, Zelalem Birhanu Aweke, and too many others to mention in the space here. Most importantly, I thank my friend, colleague, and collaborator Biruk Wendimagegn Mammo. Lastly, I thank my family for their patience and support. They have provided the encouragement, affirmation, and ultimately the purpose in completing this work. iii Table of Contents Dedication ....................................... ii Acknowledgments ................................... iii List of Tables ...................................... viii List of Figures ..................................... ix Abstract ......................................... xi Chapter 1 Introduction ...............................1 1.1 The Software Attack Surface . .2 1.1.1 The Cycle of Exploitation of the Software Attack Surface . .2 1.1.2 The Evolution and Commercialization of Malware . .5 1.1.3 Breaking the Cycle of Exploitation . .5 1.1.4 Control-Flow Attacks . .6 1.2 Contemporary Control-Flow Attacks Rely on Mixing of Control with Data .7 1.3 Hardware-Software Co-Design Can Greatly Enhance Control-Data Isolation8 1.4 Latent Software Defects are Control-Flow Path Dependent . .9 1.5 Contributions of this Work . 10 Chapter 2 Control-Data Isolation .......................... 15 2.1 Introduction . 16 2.1.1 Control-Flow Attacks . 16 2.1.2 Control-Data Isolation . 17 2.1.3 Contributions of this Chapter . 18 2.2 Protecting Control Flow with Control-Data Isolation . 19 2.2.1 Threat and Trust Model . 19 2.2.2 CDI Threat Protection . 20 2.2.3 Achieving Higher Levels of Protection by Isolating Control and Data 21 2.3 Control-Data Isolation via Elimination of Indirect Control Flow . 23 2.3.1 CFG Discovery . 24 2.3.2 Indirection Elimination . 26 2.3.3 CDI Performance Optimizations . 27 iv 2.3.4 Detecting Attacks in CDI Protected Programs . 28 2.4 CDI Implementation for Shared Libraries . 29 2.4.1 Dynamic Nature of Shared Libraries . 29 2.4.2 Enforcing CDI for Shared Libraries . 30 2.5 CDI Compliant Code for Dynamic Compilation . 32 2.5.1 Dynamically Generated Code . 32 2.5.2 Threat and Trust Model for Dynamically Generated Code . 33 2.5.3 Properties of CDI Compliant Code . 33 2.5.4 CDI-compliant Code Attestation . 34 2.6 PitBull: Compiler-Based Control-Data Isolation . 35 2.7 Experimental Evaluation . 37 2.7.1 Benchmark Applications . 38 2.7.2 Performance Evaluation . 38 2.7.3 Impact of Optimization . 38 2.8 Related Work . 40 2.8.1 Software Mechanisms . 41 2.8.2 Hardware Solutions . 43 2.9 Chapter Conclusions . 43 Chapter 3 Locking Down Insecure Indirection with Hardware-Based Control- Data Isolation ................................... 44 3.1 Introduction . 45 3.1.1 Control-Flow Attacks . 45 3.1.2 Control-Data Isolation . 46 3.1.3 Advancing CDI with Architecture Support . 47 3.1.4 Contributions of this Chapter . 48 3.2 Protecting Control Flow with Control-Data Isolation . 49 3.2.1 Threat and Trust Model . 49 3.2.2 Control-Data Isolation Mechanism . 49 3.2.3 Runtime Overheads Executing CDI-Compliant Code . 51 3.3 Architectural Acceleration of CDI . 52 3.3.1 Caching Indirect Control Transitions . 52 3.3.2 Edge Cache Architecture . 53 3.3.3 Minimizing Edge Cache Storage . 55 3.3.4 Indirect Branch Prediction with the Edge Cache . 56 3.4 Methodology . 59 3.4.1 Implementation Platform . 59 3.4.2 Benchmark Applications . 59 3.4.3 Hardware/Software Co-Design . 59 3.5 Experimental Evaluation . 60 3.5.1 Runtime Performance Analysis . 60 3.5.2 Indirect Branch Prediction Analysis . 62 3.5.3 Security Analysis . 63 3.5.4 Area and Power Analysis . 64 v 3.6 Extending Control-Data Isolation to Advance Path-Based Control-Flow Security . 65 3.6.1 Path-Based Attacks . 65 3.6.2 Impossible Paths . 66 3.6.3 Advancing Control-Data Isolation with the Non-Speculative Return Address Stack . 66 3.6.4 Contributions of the Non-Speculative Return Address Stack . 67 3.6.5 The Return Address Stack . 68 3.6.6 The Non-Speculative Return Address Stack . 68 3.6.7 Eliminating Control Path Attacks with the Non-Speculative Return Address Stack . 69 3.6.8 Detecting Stack Unwinding with the Stack Pointer Address Stack . 70 3.6.9 Dynamic Enforcement of the Valid Control-Flow Graph Edge . 70 3.6.10 Methodology of the Non-Speculative Return Address Stack . 71 3.6.11 Experimental Evaluation of the Non-Speculative Return Address Stack . 72 3.7 Related Work . 72 3.7.1 Software Mechanisms . 72 3.7.2 Hardware Solutions . 75 3.7.3 Control-Data Isolation in Contrast to CFI . 75 3.7.4 Indirect Branch Prediction . 76 3.8 Chapter Conclusions . 76 Chapter 4 Scalable Profiling for Likely Security Bug Sites ............ 77 4.1 Introduction . 77 4.1.1 Contributions of this Chapter . 79 4.1.2 Dynamic Control Frontier Discovery . 81 4.1.3 Computing the Dynamic Control Frontier . 83 4.1.4 Profiling the Dynamic Control Frontier . 83 4.1.5 Leveraging the Dynamic Control Frontier . 85 4.2 Schnauzer: A Distributed DCF Profiler . 86 4.3 Experimental Evaluation and Results . 89 4.3.1 Benchmark Applications . 89 4.3.2 Experimental Framework . 89 4.3.3 Ground Truth Dynamic Control Frontier . 90 4.3.4 Analysis of DCF Sampling . 91 4.3.5 Schnauzer Profiling Scalability . 92 4.3.6 DCF Correlation with Real Vulnerabilities . 95 4.4 Introduction . 97 4.4.1 Hot Path Analysis . 97 4.4.2 Path Analysis and Distributed Sampling . 98 4.4.3 Complementary Works . 98 4.5 Chapter Conclusions . 100 Chapter 5 Conclusion ................................ 101 vi 5.1 Dissertation Summary . 101 5.2 Future Control-Flow Security Research . 102 5.3 Conclusion . 104 Bibliography ...................................... 105 vii List of Tables Table 1.1 Escalation of Attacks and Defenses . .4 2.1 Control-Data Isolation Performance . 39 2.2 CDI Related Works . 41 3.1 Storage Size of Edge Cache and Components . 61 3.2 Edge Cache Validation Rate . 62 3.3 Predictor Array Sensitivity on Predicting Indirect Branches . 62 3.4 Indirection Misprediction Rate of CDI-Compliant Code . 63 3.5 Average Indirect Target Reduction . 64 3.6 Non-Speculative RAS Performance . 73 3.7 Non-Speculative RAS Security Performance . 74 4.1 Benchmark Applications . 91 4.2 Software Vulnerabilities Sensitized by Dynamic Control Frontier Paths . 96 viii List of Figures Figure 1.1 Heartbleed Bug Vulnerable Code . .4 1.2 Elements of This Dissertation . 14 2.1 CDI Control Flow Protection . 21 2.2 CDI Compilation Flow . 23 2.3 Indirect Instruction Target Set for CFG Construction . 25 2.4 Dynamic Profiling for CDI Optimization . 28 2.5 CDI for Shared Library Control Flow Transfer . 31 2.6 CDI Code Attestation . 35 2.7 PitBull Compilation Flow . 36.
Load more

Recommended publications
  • 2020 Sonicwall Cyber Threat Report
    2020 SONICWALL CYBER THREAT REPORT sonicwall.com I @sonicwall TABLE OF CONTENTS 3 A NOTE FROM BILL 4 CYBERCRIMINAL INC. 11 2019 GLOBAL CYBERATTACK TRENDS 12 INSIDE THE SONICWALL CAPTURE LABS THREAT NETWORK 13 KEY FINDINGS FROM 2019 13 SECURITY ADVANCES 14 CRIMINAL ADVANCES 15 FASTER IDENTIFICATION OF ‘NEVER-BEFORE-SEEN’ MALWARE 16 TOP 10 CVES EXPLOITED IN 2019 19 ADVANCEMENTS IN DEEP MEMORY INSPECTION 23 MOMENTUM OF PERIMETER-LESS SECURITY 24 PHISHING DOWN FOR THIRD STRAIGHT YEAR 25 CRYPTOJACKING CRUMBLES 27 RANSOMWARE TARGETS STATE, PROVINCIAL & LOCAL GOVERNMENTS 31 FILELESS MALWARE SPIKES IN Q3 32 ENCRYPTED THREATS GROWING CONSISTENTLY 34 IOT ATTACK VOLUME RISING 35 WEB APP ATTACKS DOUBLE IN 2019 37 PREPARING FOR WHAT’S NEXT 38 ABOUT SONICWALL 2 A NOTE FROM BILL The boundaries of your digital empire are In response, SonicWall and our Capture Labs limitless. What was once a finite and threat research team work tirelessly to arm defendable space is now a boundless organizations, enterprises, governments and territory — a vast, sprawling footprint of businesses with actionable threat devices, apps, appliances, servers, intelligence to stay ahead in the global cyber networks, clouds and users. arms race. For the cybercriminals, it’s more lawless And part of that dedication starts now with than ever. Despite the best intentions of the 2020 SonicWall Cyber Threat Report, government agencies, law enforcement and which provides critical threat intelligence to oversight groups, the current cyber threat help you better understand how landscape is more agile than ever before. cybercriminals think — and be fully prepared for what they’ll do next.
    [Show full text]
  • Internet Security Threat Report Volume 24 | February 2019
    ISTRInternet Security Threat Report Volume 24 | February 2019 THE DOCUMENT IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE. INFORMATION OBTAINED FROM THIRD PARTY SOURCES IS BELIEVED TO BE RELIABLE, BUT IS IN NO WAY GUARANTEED. SECURITY PRODUCTS, TECHNICAL SERVICES, AND ANY OTHER TECHNICAL DATA REFERENCED IN THIS DOCUMENT (“CONTROLLED ITEMS”) ARE SUBJECT TO U.S. EXPORT CONTROL AND SANCTIONS LAWS, REGULATIONS AND REQUIREMENTS, AND MAY BE SUBJECT TO EXPORT OR IMPORT REGULATIONS IN OTHER COUNTRIES. YOU AGREE TO COMPLY STRICTLY WITH THESE LAWS, REGULATIONS AND REQUIREMENTS, AND ACKNOWLEDGE THAT YOU HAVE THE RESPONSIBILITY TO OBTAIN ANY LICENSES, PERMITS OR OTHER APPROVALS THAT MAY BE REQUIRED IN ORDER FOR YOU TO EXPORT, RE-EXPORT, TRANSFER IN COUNTRY OR IMPORT SUCH CONTROLLED ITEMS. TABLE OF CONTENTS 1 2 3 BIG NUMBERS YEAR-IN-REVIEW FACTS AND FIGURES METHODOLOGY Formjacking Messaging Cryptojacking Malware Ransomware Mobile Living off the land Web attacks and supply chain attacks Targeted attacks Targeted attacks IoT Cloud Underground economy IoT Election interference MALICIOUS
    [Show full text]
  • Systematization of Vulnerability Discovery Knowledge: Review
    Systematization of Vulnerability Discovery Knowledge Review Protocol Nuthan Munaiah and Andrew Meneely Department of Software Engineering Rochester Institute of Technology Rochester, NY 14623 {nm6061,axmvse}@rit.edu February 12, 2019 1 Introduction As more aspects of our daily lives depend on technology, the software that supports this technology must be secure. We, as users, almost subconsciously assume the software we use to always be available to serve our requests while preserving the confidentiality and integrity of our information. Unfortunately, incidents involving catastrophic software vulnerabilities such as Heartbleed (in OpenSSL), Stagefright (in Android), and EternalBlue (in Windows) have made abundantly clear that software, like other engineered creations, is prone to mistakes. Over the years, Software Engineering, as a discipline, has recognized the potential for engineers to make mistakes and has incorporated processes to prevent such mistakes from becoming exploitable vulnerabilities. Developers leverage a plethora of processes, techniques, and tools such as threat modeling, static and dynamic analyses, unit/integration/fuzz/penetration testing, and code reviews to engineer secure software. These practices, while effective at identifying vulnerabilities in software, are limited in their ability to describe the engineering failures that may have led to the introduction of vulnerabilities. Fortunately, as researchers propose empirically-validated metrics to characterize historical vulnerabilities, the factors that may have led to the introduction of vulnerabilities emerge. Developers must be made aware of these factors to help them proactively consider security implications of the code that they contribute. In other words, we want developers to think like an attacker (i.e. inculcate an attacker mindset) to proactively discover vulnerabilities.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • A Survey of Hardware-Based Control Flow Integrity (CFI)
    A survey of Hardware-based Control Flow Integrity (CFI) RUAN DE CLERCQ∗ and INGRID VERBAUWHEDE, KU Leuven Control Flow Integrity (CFI) is a computer security technique that detects runtime attacks by monitoring a program’s branching behavior. This work presents a detailed analysis of the security policies enforced by 21 recent hardware-based CFI architectures. The goal is to evaluate the security, limitations, hardware cost, performance, and practicality of using these policies. We show that many architectures are not suitable for widespread adoption, since they have practical issues, such as relying on accurate control flow model (which is difficult to obtain) or they implement policies which provide only limited security. CCS Concepts: • Security and privacy → Hardware-based security protocols; Information flow control; • General and reference → Surveys and overviews; Additional Key Words and Phrases: control-flow integrity, control-flow hijacking, return oriented programming, shadow stack ACM Reference format: Ruan de Clercq and Ingrid Verbauwhede. YYYY. A survey of Hardware-based Control Flow Integrity (CFI). ACM Comput. Surv. V, N, Article A (January YYYY), 27 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Today, a lot of software is written in memory unsafe languages, such as C and C++, which introduces memory corruption bugs. This makes software vulnerable to attack, since attackers exploit these bugs to make the software misbehave. Modern Operating Systems (OSs) and microprocessors are equipped with security mechanisms to protect against some classes of attacks. However, these mechanisms cannot defend against all attack classes. In particular, Code Reuse Attacks (CRAs), which re-uses pre-existing software for malicious purposes, is an important threat that is difficult to protect against.
    [Show full text]
  • Control-Flow Analysis of Functional Programs
    Control-flow analysis of functional programs JAN MIDTGAARD Department of Computer Science, Aarhus University We present a survey of control-flow analysis of functional programs, which has been the subject of extensive investigation throughout the past 30 years. Analyses of the control flow of functional programs have been formulated in multiple settings and have led to many different approximations, starting with the seminal works of Jones, Shivers, and Sestoft. In this paper, we survey control-flow analysis of functional programs by structuring the multitude of formulations and approximations and comparing them. Categories and Subject Descriptors: D.3.2 [Programming Languages]: Language Classifica- tions—Applicative languages; F.3.1 [Logics and Meanings of Programs]: Specifying and Ver- ifying and Reasoning about Programs General Terms: Languages, Theory, Verification Additional Key Words and Phrases: Control-flow analysis, higher-order functions 1. INTRODUCTION Since the introduction of high-level languages and compilers, much work has been devoted to approximating, at compile time, which values the variables of a given program may denote at run time. The problem has been named data-flow analysis or just flow analysis. In a language without higher-order functions, the operator of a function call is apparent from the text of the program: it is a lexically visible identifier and therefore the called function is available at compile time. One can thus base an analysis for such a language on the textual structure of the program, since it determines the exact control flow of the program, e.g., as a flow chart. On the other hand, in a language with higher-order functions, the operator of a function call may not be apparent from the text of the program: it can be the result of a computation and therefore the called function may not be available until run time.
    [Show full text]
  • Viewed Through the Prism of Clausewitzian Strategy
    CYBERWAR – VIEWED THROUGH THE PRISM OF CLAUSEWITZIAN STRATEGY Commodore Vishwanathan K Ganapathi, VSM Introduction In a globalised world where speed and reliability of information exchange is thesine qua non of technological advancement, the importance of cyberspace to a country is immeasurable. Knowledge and awareness, which derive from the degree to which cyberspace can be exploited for rapidly storing, manipulating and disseminating data, have become important measures of a nation’s power.1 As a consequence, the destruction or disruption of any of the constituent elements of cyberspace from a cyber attack would not just blunt a country’s ability to gain strategic advantage from its technological superiority but would gravely threaten its security as well. Depending on their intensity and complexity, cyber attacks can inflict a wide spectrum of damage ranging from less dangerous depredations like the theft of personal information and digital heists to highly destructive actions like the disruption of critical infrastructure- ‘the facilities, systems, sites and networks necessary for the delivery of essential services and functions’2 - industrial sabotage, subversion, data destruction or theft of sensitive information. It is the latter category, most often believed to be orchestrated for political reasons by a potential adversary, which has transformed cyber attacks from being perceived as a trivial problem befitting address by an IT professional to one that merits the focus of policy planners and strategists alike.3 The concerns of governments about the gravity of the threat from cyber attacks stem from the certitude that easily accessible destructive technologies are being exploited by state and non-state actors alike to launch attacks even against powerful adversaries several thousand miles away.
    [Show full text]
  • Obfuscating C++ Programs Via Control Flow Flattening
    Annales Univ. Sci. Budapest., Sect. Comp. 30 (2009) 3-19 OBFUSCATING C++ PROGRAMS VIA CONTROL FLOW FLATTENING T. L¶aszl¶oand A.¶ Kiss (Szeged, Hungary) Abstract. Protecting a software from unauthorized access is an ever de- manding task. Thus, in this paper, we focus on the protection of source code by means of obfuscation and discuss the adaptation of a control flow transformation technique called control flow flattening to the C++ lan- guage. In addition to the problems of adaptation and the solutions pro- posed for them, a formal algorithm of the technique is given as well. A prototype implementation of the algorithm presents that the complexity of a program can show an increase as high as 5-fold due to the obfuscation. 1. Introduction Protecting a software from unauthorized access is an ever demanding task. Unfortunately, it is impossible to guarantee complete safety, since with enough time given, there is no unbreakable code. Thus, the goal is usually to make the job of the attacker as di±cult as possible. Systems can be protected at several levels, e.g., hardware, operating system or source code. In this paper, we focus on the protection of source code by means of obfuscation. Several code obfuscation techniques exist. Their common feature is that they change programs to make their comprehension di±cult, while keep- ing their original behaviour. The simplest technique is layout transformation [1], which scrambles identi¯ers in the code, removes comments and debug informa- tion. Another technique is data obfuscation [2], which changes data structures, 4 T. L¶aszl¶oand A.¶ Kiss e.g., by changing variable visibilities or by reordering and restructuring arrays.
    [Show full text]
  • Control Flow Statements
    Control Flow Statements Christopher M. Harden Contents 1 Some more types 2 1.1 Undefined and null . .2 1.2 Booleans . .2 1.2.1 Creating boolean values . .3 1.2.2 Combining boolean values . .4 2 Conditional statements 5 2.1 if statement . .5 2.1.1 Using blocks . .5 2.2 else statement . .6 2.3 Tertiary operator . .7 2.4 switch statement . .8 3 Looping constructs 10 3.1 while loop . 10 3.2 do while loop . 11 3.3 for loop . 11 3.4 Further loop control . 12 4 Try it yourself 13 1 1 Some more types 1.1 Undefined and null The undefined type has only one value, undefined. Similarly, the null type has only one value, null. Since both types have only one value, there are no operators on these types. These types exist to represent the absence of data, and their difference is only in intent. • undefined represents data that is accidentally missing. • null represents data that is intentionally missing. In general, null is to be used over undefined in your scripts. undefined is given to you by the JavaScript interpreter in certain situations, and it is useful to be able to notice these situations when they appear. Listing 1 shows the difference between the two. Listing 1: Undefined and Null 1 var name; 2 // Will say"Hello undefined" 3 a l e r t( "Hello" + name); 4 5 name= prompt( "Do not answer this question" ); 6 // Will say"Hello null" 7 a l e r t( "Hello" + name); 1.2 Booleans The Boolean type has two values, true and false.
    [Show full text]
  • Control Flow Statements in Java Tutorials Point
    Control Flow Statements In Java Tutorials Point Cnidarian and Waldenses Bubba pillar inclemently and excorticated his mong troublesomely and hereabout. andRounding convective and conversational when energises Jodi some cudgelled Anderson some very prokaryote intertwiningly so wearily! and pardi? Is Gordon always scaphocephalous Go a certain section, commercial use will likely somewhere in java, but is like expression representation of flow control for loop conditionals are independent prognostic factors In this disease let's delve deep into Java Servlets and understand when this. Java Control Flow Statements CoreJavaGuru. Loops in Java Tutorialspointdev. Advantages of Java programming Language. Matlab object On what Kitchen Floor. The flow of controls cursor positioning of files correctly for the python and we represent the location of our java entry points and times as when exploits are handled by minimizing the. The basic control flow standpoint the typecase construct one be seen to realize similar to. Example- Circumference of Circle 227 x Diameter Here This technique. GPGPU GPU Java JCuda For example charity is not discount to control utiliza- com A. There are 3 types of two flow statements supported by the Java programming language Decision-making statements if-then they-then-else switch Looping. Java IfElse Tutorial W3Schools. Spring batch passing data between steps. The tutorial in? Remove that will need to point handling the tutorial will be used or run unit of discipline when using this statement, easing the blinking effect. Either expressed or database systems support for tcl as a controlling source listing applies to a sending field identifier names being part and production.
    [Show full text]
  • 2019 Sonicwall Cyber Threat Report
    MID-YEAR UPDATE | JULY 2019 2019 SONICWALL CYBER THREAT REPORT Arm Your Business with the Latest Threat Intelligence from the First Half of 2019 SONICWALL CAPTURE LABS 1 MILLION + THREAT NETWORK Sensors 215 + Countries & Territories 24 x 7 x 365 Monitoring < 24 HOURS Threat Response 140K + Malware Samples Collected Daily 28M + Attacks BlockeD Daily 2019 GLOBAL CYBER ARMS RACE 2018 1H 2019 1H SonicWall recorded more than 4.78 billion malware attacKs for the first half of 2019 — a 20% year-to-date 5.99 Billion decrease. 4.78 Billion Global malware volume dips to start 2019, but other attack types rebound. MALWARE INTRUSION WEB APP RANSOMWARE IOT ENCRYPTED CYBERATTACK TRENDS ATTACKS ATTEMPTS ATTACKS ATTACKS MALWARE THREATS 76% 55% As global malware 11% 15% volume declines, 4% other attacK types increase during -20% the first half of 2019. 4.8 BILLION 2.0 TRILLION 19.2 MILLION 110.9 MILLION 13.5 MILLION 2.5 MILLION 2019 MALWARE VOLUME: TOP GLOBAL COUNTRIES 2019 Malware Attacks Top Countries Malware attacks 52.0 are largely down in France -53% 2019 witH a few Netherlands 56.5 +3% exceptions. Germany 66.5 -63% Switzerland 75.9 +72% InDia (25%), SwitzerlanD Brazil -4% 121.2 (72%) anD tHe China -61% 138.3 NetHerlanDs (3%) were the top coUntries that Canada -11% 155.4 sUffereD increaseD India +25% 226.9 malware activity. United Kingdom -9% 313.6 United States -17% 2,494.5 - 500 1,000 1,500 2.000 2,500 3,000 MILLIONS RANSOMWARE STILL RISING Ransomware VolUme YTD 110.9 Million Ransomware AttacKs 1H 2018 1H 2019 Change U.K.
    [Show full text]
  • Indicative Guidelines for Chemical Safety and Security in Small and Medium-Sized Enterprises to Foster the Peaceful Uses of Chemistry
    Indicative Guidelines for Chemical Safety and Security in Small and Medium-sized Enterprises to Foster the Peaceful Uses of Chemistry OPCW Organisation for the Prohibition of Chemical Weapons © Organisation for the Prohibition of Chemical Weapons, The Hague, the Netherlands, 2021 No use of this document may be made for any commercial purpose whatsoever without prior permission in writing from the OPCW. The views expressed in any article of this document do not necessarily represent those of the OPCW and the OPCW accepts no responsibility for them. Mention of the names of firms and commercial products does not imply endorsement by the OPCW. The use of general descriptive names, registered names, trademarks, etc. does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Editors: N. Kojevnikov, L. Zhao, H. Mat Som, T. Zhang Indicative Guidelines for Chemical Safety and Security in Small and Medium-sized Enterprises to Foster the Peaceful Uses of Chemistry The Outcome of the Workshops on Developing Tools for Chemical Safety and Security Management TABLE OF CONTENTS 1 PREFACE ..................................................................................................................... 1 2 TABLE OF ACRONYMS AND ABBREVIATIONS ............................................... 3 3 INTRODUCTION ........................................................................................................ 5 3.1 Role of the Employer ...........................................................................................
    [Show full text]