DOCSLIB.ORG

Writing Secure Code / Michael Howard, David Leblanc

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Writing Secure Code / Michael Howard, David Leblanc Copyright 2002 by Microsoft Corporation PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2002 by Microsoft Corporation All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. Library of Congress Cataloging-in-Publication Data Howard, Michael, 1965– Writing Secure Code / Michael Howard, David LeBlanc. p. cm. ISBN 0-7356-1588-8 1. Computer security. 2. Data encryption (Computer science) I. LeBlanc, David, 1960– II. Title. QA76.9.A25 H698 2001 005.8--dc21 2001044546 Printed and bound in the United States of America. 1 2 3 4 5 6 7 8 9 QWE 6 5 4 3 2 Distributed in Canada by Penguin Books Canada Limited. A CIP catalogue record for this book is available from the British Library. Microsoft Press books are available through booksellers and distributors worldwide. For further information about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax (425) 706-7329. Visit our Web site at www.microsoft.com/mspress. Send comments to [email protected]. Active Directory, ActiveX, Authenticode, Hotmail, Jscript, Microsoft, Microsoft Press, MS-DOS, MSDN, Visual Basic, Visual C++, Visual Studio, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Acquisitions Editor: Danielle Bird Project Editor: Devon Musgrave Technical Editor: Julie Xiao Dedication To Blake, God߀™s little gift to Cheryl and me. To Cheryl, Blake could not ask for a more wonderful mother. ߀” Michael To Jennifer, for putting up with many lost weekends when we could have been out horseback riding. ߀”David In memory of all those people who needlessly perished on September 11, 2001. Foreword Improving security was a major focus while we were developing Windows 2000. At one point, we decided to run an unusual experiment to test the product߀™s mettle before we released it. We set up a Windows 2000 Web server called ߀?Windows2000test.com,߀• put it out there, and waited to see what happened. We made no announcement of any kind; we didn߀™t call any attention to it in any way whatsoever. Within a couple of hours, hundreds of people were already trying to hack it. Within days, tens of thousands of people were hammering away. These days, as soon as a product gets into their hands, hackers begin an intensive effort to find and exploit security holes. If the product developers don߀™t make an equally intensive effort to build security into their code, the hackers will almost surely succeed. A product߀™s security is every bit as important as its features. Don߀™t get me wrong߀”people would have no reason to buy a product without great features. But while developers know how to build features, they often don߀™t know how to design and build security. This book changes that. Writing Secure Code offers practical insights into secure design, secure coding, and testing techniques, many of which are not documented elsewhere. It will give you a richer understanding of what it takes to build secure applications. Michael and David are, respectively, members of the Secure Windows Initiative and the Trustworthy Computing Security Team at Microsoft. They have witnessed firsthand the sometimes basic coding mistakes that undermine product security, and their projects have helped us significantly improve how we designed and implemented security in products such as Windows 2000 and Windows XP. Their goal in writing this book is to pass on to you, the developer community, everything Microsoft has learned. Brian Valentine Senior Vice President, Windows Division Microsoft Corporation Acknowledgments When you look at the cover of this book, you see the names of only two authors, but this book would be nothing if we didn߀™t get help and input from numerous people. We pestered some people until they were sick of us, but still they were only too happy to help. First, we߀™d like to thank the Microsoft Press folks, including Danielle Bird for agreeing to take on this book, Devon Musgrave for turning ߀?Geek߀• into English and managing not to complain too much, and Julie Xiao for making sure we were not lying. Much thanks also to Elizabeth Hansford for laying out pages, Rob Nance for the part opener art, and Shawn Peck for copyediting. Many people answered questions to help make this book as accurate as possible, including the following from Microsoft: Saji Abraham, Eli Allen, John Biccum, Scott Culp, Thomas Deml, Monica Ene-Pietrosanu, Sean Finnegan, Tim Fleehart, Damian Haase, David Hubbard, Mike Lai, Louis Lafreniere, Brian LaMacchia, John Lambert, Lawrence Landauer, Paul Leach, Terry Leeper, Steve Lipner, Rui Maximo, Daryl Pecelj, Jon Pincus, Fritz Sands, Eric Schultze, Alex Stockton, Matt Thomlinson, Hank Voight, Chris Walker, Richard Ward, Richard Waymire, Mark Zbikowski, and Mark Zhou. We߀™d especially like to thank the following ߀™softies: Russ Wolfe, who explained numerous Unicode and UTF-8 issues and wouldn߀™t shut up until we had the issues documented adequately. Kamen Moutafov, a genuinely nice guy, who spent numerous hours helping with the RPC section. He߀™s one of those developers who answers stupid questions without making you feel dumb. Erik Olsen went to great lengths to make sure the .NET issues were nailed down. If it weren߀™t for Erik, Chapter 13 would be tiny. Eric Jarvi read most all the chapters and helped immensely by offering numerous improvements, most of which started with, ߀?You really should explain߀¦ß€• We want to point out that Kamen, Erik, and Eric rock. They diligently reviewed material while they were in the final stages of shipping their respective products: Windows XP, the .NET Framework, and Visual Studio .NET. It would have been easy for them to say, ߀?I߀™m busy, leave me alone,߀• but they didn߀™t. They could see that some short-term time spent getting this book right would have long-term benefits for themselves (as they won߀™t have to answer the same questions time and again), for Microsoft, and, most important, for our shared and valued customers. Many outside Microsoft gave their time to help us with this book. We߀™d like to give our greatest thanks to Rain Forest Puppy for providing first-rate Web security comments. By the way, Mr. Puppy, no offense taken! John Pescatore of Gartner Inc. for his insightful (and blunt) comments, which helped shape the early chapters. Professor Jesper Johansson of Boston University, who read every word, sentence, paragraph, and chapter of the book and had comments on every word, sentence, paragraph, and chapter of the book! Leslee LaFountain of the NSA for showing such great interest in this book. And, finally, the Secure Windows Initiative team. We thank you all. Introduction This is a book both of us have wanted to write for a long time. We߀™re both involved in convincing and teaching people how to make their applications secure from attack, and until recently few people have cared about secure systems. Don߀™t get us wrong: some people truly do want to ship great products, and by great, we also mean secure. One of us߀”Michael߀”remembers writing his first program in Microsoft Windows in 1984. It was a simple program, not dissimilar to the canonical ߀?Hello, World߀• program defined in Kernighan and Ritchie߀™s classic book The C Programming Language (Prentice Hall PTR, 1988, second edition). He was so excited when the application compiled, linked, and ran for the first time, and we߀™re sure that any of you who worked on the early versions of Windows will remember how difficult it was to create Windows applications back then. The Windows SDK and Microsoft C compiler combination was not an easy one to learn, especially if you came from a text-based background such as MS-DOS, PC-DOS, or UNIX. Looking back at that first application in 1984, we both have considered whether it was secure from attack. And the simple answer is, yes, it was. It was secure simply because no one hooked Windows 1.x߀“based computers to any kind of network, let alone the Internet. It was also secure because cybercrime and Internet-based vandalism wasn߀™t a rampant problem in 1984. How times have changed! Today߀™s Internet environment is incredibly hostile, and all applications must be designed with this in mind. If the PC running Windows 1.x were hooked to the Internet today, the application would certainly be attacked. It was never designed to run in such a hostile environment. To be honest, the application was not designed with security in mind whatsoever because Michael knew next to nothing about secure coding back then. Few of us did, and those few certainly did not to the same extent that many people understand secure code today. By secure code, we don߀™t mean security code or code that implements security features. We mean code that is designed to withstand attack by malicious attackers. Secure code is also robust code. Teaching you to design, write, and test application code in a secure manner is the sole purpose of this book.
Load more

Recommended publications
  • Medtronic Care Management Services, LLC CC FM TLS/SRTP FIPS 140
    Medtronic Care Management Services, LLC CC FM TLS/SRTP FIPS 140‐2 Cryptographic Module Non‐Proprietary Security Policy Version: 1.6 Date: March 16, 2016 Copyright Medtronic Care Management Services 2016 Version 1.6 Page 1 of 14 Medtronic Care Management Services Public Material – May be reproduced only in its original entirety (without revision). Table of Contents 1 Introduction .................................................................................................................... 4 1.1 Cryptographic Boundary ..............................................................................................................5 1.2 Mode of Operation .......................................................................................................................5 2 Cryptographic Functionality ............................................................................................. 6 2.1 Critical Security Parameters .........................................................................................................7 2.2 Public Keys ....................................................................................................................................8 3 Roles, Authentication and Services .................................................................................. 8 3.1 Assumption of Roles .....................................................................................................................8 3.2 Services and CSP Access Rights ....................................................................................................8
    [Show full text]
  • No Random, No Ransom: a Key to Stop Cryptographic Ransomware
    No Random, No Ransom: A Key to Stop Cryptographic Ransomware Ziya Alper Genç, Gabriele Lenzini, and Peter Y.A. Ryan Interdisciplinary Centre for Security Reliability and Trust (SnT) University of Luxembourg Abstract. To be effective, ransomware has to implement strong encryp- tion, and strong encryption in turn requires a good source of random numbers. Without access to true randomness, ransomware relies on the pseudo random number generators that modern Operating Systems make available to applications. With this insight, we propose a strategy to miti- gate ransomware attacks that considers pseudo random number generator functions as critical resources, controls accesses on their APIs and stops unauthorized applications that call them. Our strategy, tested against 524 active real-world ransomware samples, stops 94% of them, including WannaCry, Locky, CryptoLocker and CryptoWall. Remarkably, it also nullifies NotPetya, the latest offspring of the family which so far has eluded all defenses. Keywords: ransomware, cryptographic malware, randomness, mitigation. 1 Introduction Ransomware is a malware, a malicious software that blocks access to victim’s data. In contrast to traditional malware, whose break-down is permanent, ransomware’s damage is reversible: access to files can be restored on the payment of a ransom, usually a few hundreds US dollars in virtual coins. Despite being relatively new, this cyber-crime is spreading fast and it is believed to become soon a worldwide pandemic. According to [24], a US Govern- ment’s white paper dated June 2016, on average more than 4,000 ransomware attacks occurred daily in the USA. This is 300-percent increase from the previous year and such important increment is probably due to the cyber-crime’s solid business model: with a small investment there is a considerable pecuniary gain which, thanks to the virtual currency technology, can be collected reliably and in a way that is not traceable by the authorities.
    [Show full text]
  • Cryptanalysis of the Random Number Generator of the Windows Operating System
    Cryptanalysis of the Random Number Generator of the Windows Operating System Leo Dorrendorf School of Engineering and Computer Science The Hebrew University of Jerusalem 91904 Jerusalem, Israel [email protected] Zvi Gutterman Benny Pinkas¤ School of Engineering and Computer Science Department of Computer Science The Hebrew University of Jerusalem University of Haifa 91904 Jerusalem, Israel 31905 Haifa, Israel [email protected] [email protected] November 4, 2007 Abstract The pseudo-random number generator (PRNG) used by the Windows operating system is the most commonly used PRNG. The pseudo-randomness of the output of this generator is crucial for the security of almost any application running in Windows. Nevertheless, its exact algorithm was never published. We examined the binary code of a distribution of Windows 2000, which is still the second most popular operating system after Windows XP. (This investigation was done without any help from Microsoft.) We reconstructed, for the ¯rst time, the algorithm used by the pseudo- random number generator (namely, the function CryptGenRandom). We analyzed the security of the algorithm and found a non-trivial attack: given the internal state of the generator, the previous state can be computed in O(223) work (this is an attack on the forward-security of the generator, an O(1) attack on backward security is trivial). The attack on forward-security demonstrates that the design of the generator is flawed, since it is well known how to prevent such attacks. We also analyzed the way in which the generator is run by the operating system, and found that it ampli¯es the e®ect of the attacks: The generator is run in user mode rather than in kernel mode, and therefore it is easy to access its state even without administrator privileges.
    [Show full text]
  • Vulnerabilities of the Linux Random Number Generator
    Black Hat 2006 Open to Attack Vulnerabilities of the Linux Random Number Generator Zvi Gutterman Chief Technology Officer with Benny Pinkas Tzachy Reinman Zvi Gutterman CTO, Safend Previously a chief architect in the IP infrastructure group for ECTEL (NASDAQ:ECTX) and an officer in the Israeli Defense Forces (IDF) Elite Intelligence unit. Master's and Bachelor's degrees in Computer Science from the Israeli Institute of Technology. Ph.D. candidate at the Hebrew University of Jerusalem, focusing on security, network protocols, and software engineering. - Proprietary & Confidential - Safend Safend is a leading provider of innovative endpoint security solutions that protect against corporate data leakage and penetration via physical and wireless ports. Safend Auditor and Safend Protector deliver complete visibility and granular control over all enterprise endpoints. Safend's robust, ultra- secure solutions are intuitive to manage, almost impossible to circumvent, and guarantee connectivity and productivity, without sacrificing security. For more information, visit www.safend.com. - Proprietary & Confidential - Pseudo-Random-Number-Generator (PRNG) Elementary and critical component in many cryptographic protocols Usually: “… Alice picks key K at random …” In practice looks like random.nextBytes(bytes); session_id = digest.digest(bytes); • Which is equal to session_id = md5(get next 16 random bytes) - Proprietary & Confidential - If the PRNG is predictable the cryptosystem is not secure Demonstrated in - Netscape SSL [GoldbergWagner 96] http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Apache session-id’s [GuttermanMalkhi 05] http://www.gutterman.net/publications/2005/02/hold_your_sessions_an_attack_o.html - Proprietary & Confidential - General PRNG Scheme 0 0 01 Stateseed 110 100010 Properties: 1. Pseudo-randomness Output bits are indistinguishable from uniform random stream 2.
    [Show full text]
  • Wheel of Fortune ANALYZING EMBEDDED OS (CS)PRNGS
    Wheel of Fortune ANALYZING EMBEDDED OS (CS)PRNGS JOS WETZELS ALI ABBASI WHOIS • Jos Wetzels1,2 • Researcher, MSc student • samvartaka.github.io • Ali Abbasi1,3 • Ph.D. candidate • http://wwwhome.cs.utwente.nl/~abbasia/ 1Distributed and Embedded System Security (DIES) group, University of Twente, Netherlands 2SEC Group, Eindhoven University of Technology, Netherlands 3SYSSEC Group, Ruhr-University Bochum, Germany ABOUT • Introduction to Embedded OS Random Number Generators • Embedded Challenges Overview • Case Studies • Product of ongoing research EMBEDDED SYSTEMS ARE EVERYWHERE EMBEDDED SYSTEMS ARE BOOMING © DigiReach EMBEDDED RANDOMNESS IS HARD ROADMAP • Why Does This Matter? • OS PRNGs • Embedded Challenges • Case Studies SOME TERMS • Interested in random bits • Cannot predict next bit with Pr. > 0.5 • Entropy (Shannon / Renyi / …) • Measure of information unpredictability • High entropy → very random WHY RANDOMNESS IS IMPORTANT? • Cryptography • Keys, Nonces, Etc. • Exploit Mitigations • ASLR → Randomize address space • Stack Smashing Protection → Randomize canaries • Randomness is critical to security ecosystem • Failure has massive impact TRUE RANDOM NUMBER GENERATORS • Physical (‘true’) entropy source • Radioactive Decay, Shot Noise, Etc. • Two ways to implement it: • External (dedicated device) • Trusted Platform Module (TPM) • Hardware Security Module (HSM) • Integrated • Intel Ivy Bridge RdRand • Certain Smartcards • Downsides • Expensive • Portability issues PSEUDO RANDOM NUMBER GENERATORS • Software based • Deterministic algorithm
    [Show full text]
  • Programmation Utilisant Les Interruptions Du Syst`Eme D’Exploitation : Le Cas De MS-DOS
    Programmation utilisant les interruptions du syst`eme d’exploitation : le cas de MS-DOS Patrick C´egielski Janvier 2019 Pour Ir`ene et Marie Legal Notice Copyright c 2019 Patrick C´egielski Universit´eParis XII – IUT de S´enart-Fontainebleau Route foresti`ere Hurtault F-77300 Fontainebleau [email protected] iv Table des mati`eres Pr´eface ix 0.1 Bibliographie ...................................... x 1 Lesgrandesfonctionsd’unsyst`emed’exploitation 1 1.1 Etudeg´en´erale´ ..................................... 2 1.1.1 Les deux tˆaches d’un syst`eme d’exploitation . .... 2 1.1.2 Principe des syst`emes d’exploitation . 3 1.2 CasdeMS-DOS .................................... 5 1.2.1 Mod`eleentroiscouches ............................ 5 1.3 Historique........................................ 6 1.4 Bibliographie ...................................... 9 I Le syst`eme d’exploitation comme machine virtuelle 11 2 Programmer avec le DOS 13 2.1 Lesentr´ees-sortiesstandard . ....... 14 2.1.1 Fonction 02h d’affichaged’uncaract`ere . 14 2.1.2 Fonction 01h desaisied’uncaract`ereavec´echo . 15 2.1.3 Fonction 08h desaisied’uncaract`eresans´echo . 17 2.1.4 Saisie d’une chaˆıne de caract`eres . .. 17 2.2 L’interruption 33h de manipulation de la souris . 18 2.2.1 Fonction 00h d’initialisation de la souris . 18 2.2.2 Fonctions 01h et 02h d’affichage et de transparence du pointeur . 18 2.2.3 Fonction 03h de r´ecup´eration de la position du pointeur . 19 2.2.4 Fonction 04h ded´eplacementdupointeur . 20 2.3 Fonction 05h d’impression............................... 21 2.4 Lesyst`eme ....................................... 22 2.4.1 Fonction 2Ah d’obtentiondeladate ..................... 22 2.4.2 R´ecup´eration de l’heure .
    [Show full text]
  • Security Policy for FIPS 140-2 Validation
    Enhanced Cryptographic Provider Security Policy for FIPS 140‐2 Validation Microsoft Windows 8 Microsoft Windows Server 2012 Microsoft Windows RT Microsoft Surface Windows RT Microsoft Surface Windows 8 Pro Microsoft Windows Phone 8 Microsoft Windows Storage Server 2012 Enhanced Cryptographic Provider (RSAENH.DLL) DOCUMENT INFORMATION Version Number 1.2 Updated On December 17, 2014 © 2014 Microsoft. All Rights Reserved Page 1 of 25 This Security Policy is non‐proprietary and may be reproduced only in its original entirety (without revision). Enhanced Cryptographic Provider The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. This work is licensed under the Creative Commons Attribution-NoDerivs- NonCommercial License (which allows redistribution of the work). To view a copy of this license, visit http://creativecommons.org/licenses/by-nd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
    [Show full text]
  • Swsoft Gewinnt Ex-Microsoft-Systemarchitekten Als Senior Technical Advisor
    SWsoft gewinnt Ex-Microsoft-Systemarchitekten als Senior Technical Advisor Mark Zbikowski kommt mit Expertenwissen über Windows- Systemprogrammierung zum Unternehmen für Virtualisierungs- und Automatisierungssoftware Darmstadt, 17.01.2008. – SWsoft vermeldet einen prominenten neuen Berater: Mark Zbikowski, ehemaliger Systemarchitekt bei Microsoft und einer der Pioniere der Softwareentwicklung überhaupt, wird für das Unternehmen als Senior Technical Advisor tätig. In dieser Funktion wird er SWsoft unterstützen, indem er das Entwicklungsteam und die Führungskräfte berät. Während seiner Zeit bei Microsoft leitete Zbikowski MS-DOS-, OS/2-, Cairo- und NT-Projekte. Im Jahre 2006 wurde er für seine 25 Dienstjahre in der Firma geehrt und war der erste Mitarbeiter - nach Bill Gates und Steve Ballmer - der diese Karrieremarke erreichte. Zbikowski entwarf das Dateiformat der „EXE“-Programme unter MS-DOS; seine Initialen „MZ“ zieren bis heute die Kopfdaten dieses Formats für ausführbare Dateien. Er war ein wichtiger Designer und Entwickler für das gängigste Dateisystem Windows NTFS. Heute lehrt Zbikowski an der University of Washington, nachdem er im Juni 2006 bei Microsoft ausgeschieden war. Er besitzt einen von Harvard verliehenen Bachelor-Grad in angewandter Mathematik und einen Master-Abschluss von Yale. "Die Unternehmenskultur bei SWsoft erinnert an die aufregenden Anfangsjahre von Microsoft – eine junge Firma voller Energie und mit riesigen Chancen, die Veränderungen wesentlich mitzugestalten, die es im Einsatz der Informationstechnologie zum Nutzen von Verbrauchern und Unternehmen überall auf der Welt geben wird“, sagt Zbikowski. „Ich freue mich sehr auf den Beginn meiner Mitarbeit an SWsofts kontinuierlicher Entwicklung von Weltklasse-Software für Virtualisierung, Management und Automatisierung.“ “Marks Erfahrungen mit der Erstellung von Systemkomponenten für die meistverbreitete Software weltweit – Microsoft Windows – sind von großer Bedeutung für unsere Arbeit", so Serguei Beloussov, CEO bei SWsoft.
    [Show full text]
  • Random Number Generator
    Random number generator A random number generator (often abbreviated as RNG) is a computational or physical device designed to generate a sequence of numbers or symbols that lack any pattern, i.e. appear random . Computer-based systems for random number generation are widely used, but often fall short of this goal, though they may meet some statistical tests for randomness intended to ensure that they do not have any easily discernible patterns. Methods for generating random results have existed since ancient times, including dice , coin flipping , the shuffling of playing cards , the use of yarrow stalks in the I Ching , and many other techniques. "True" random numbers vs. pseudo-random numbers There are two principal methods used to generate random numbers. One measures some physical phenomenon that is expected to be random and then compensates for possible biases in the measurement process. The other uses computational algorithms that produce long sequences of apparently random results, which are in fact determined by a shorter initial seed or key. The latter type are often called pseudo-random number generators . A "random number generator" based solely on deterministic computation cannot be regarded as a "true" random number generator, since its output is inherently predictable. John von Neumann famously said "Anyone who uses arithmetic methods to produce random numbers is in a state of sin." How to distinguish a "true" random number from the output of a pseudo-random number generator is a very difficult problem. However, carefully chosen pseudo-random number generators can be used instead of true random numbers in many applications.
    [Show full text]
  • 1Password Security Design White Paper
    1Password Security Design 1Password Memberships [git] • Branch: main @ adb528d • Release: v0.3.1 (2021-04-19) Head tags: v0.3.1 Key Security Features 1Password offers a number of notable security features, including True end-to-end encryption All cryptographic keys are generated and man- aged by the client on your devices, and all encryption is done locally. Details are in A deeper look at keys. Server ignorance We are never in the position of learning your Master Password or your cryptographic keys. Details are in A modern ap- proach to authentication. Nothing “crackable” is stored Often a server will store the password hash. If captured, this can be used in password cracking attempts. Our two-secret key derivation mixes your locally held Secret Key with your Master Password so that data we store cannot be used in cracking attempts. See Making verifiers uncrackable with 2SKD for details. Thrice encrypted in transport When your already encrypted data travels between your device and our servers, it is encrypted and authenti- cated by Transport Layer Security (TLS) and our own transport en- cryption. Details are in Transport Security. You control sharing Only someone who holds the keys to a vault can share that data with someone else. We do not have those keys, so sharing decisions come from you. See How Vault Items Are Securely Shared for details. Team managed data recovery We do not have the ability to recover your data if you forget your Master Password or lose your Secret Key (since you have end-to-end security). But recovery keys can be shared with team members.
    [Show full text]
  • Portable Executable מאת Spl0it
    Portable Executable מאת Spl0it הקדמה - מה זה PE? ויקיפדיה: "PE )קיצור של Portable Executable( הוא פורמט שפותח ע"י Microsoft עבור קבצי ריצה, קבצי אובייקט, ספריות קישור-דינמי )DLL(, קבצי פונטים )FON( ועוד אשר משומשים בגרסאות ה32- וה- 64 ביט של מערכות המשתמשות במערכת ההפעלה PE .Windows הוא מבנה נתונים אשר מקבץ את המידע ההכרחי בשביל שה-Loader של Windows יצליח לנהל את הקוד בזמן ריצה". סוגי הקבצים הנפוצים ביותר המשתמשים בפורמט PE: exe - קובץ ריצה dll - ספריית קישור-דינמי sys/drv - קובץ מערכת )דרייבר לקרנל( ocx - קובץ שליטה ב-ActiveX cpl - לוח בקרה scr - שומר מסך הערה: לקבצי lib. )ספריות סטטיות( יש פורמט שונה, לא PE. מערכת ההפעלה Windows עושה שימוש בקבועים הנ"ל כדי לייצג גדלים של משתנים: גודל טיפוס בית CHAR (Character) 1 2 בתים WORD 2 בתים (SHORT (Short Integer 4 בתים (DWORD (Double Word 4 בתים (LONG (Long Integer 8 בתים (QWORD (Quad Word 8 בתים LONGLONG כלים לחקירת ה-PE: PEView - לטובת הסתכלות על ה-PE של קבצים בפורמט זה CFF Explorer - אותו דבר, אך עם פיצ'רים נוספים כגון עריכת ה-PE בהקסדצימלי והמרת הקובץ לשפת אסמבלי WinDbg - עבור ניפוי שגיאות )Debugging( בסיסי פורמט ה-PE נראה כך )התמונה ממוספרת כדי שההסברים בהמשך המאמר יהיו ברורים יותר. לתמונה "נקייה" יותר, לחצו כאן(: Portable Executable www.DigitalWhisper.co.il גליון 90, ינואר 2018 2 DOS-Header המבנה הראשון, הנמצא ב-0x0 Offset, נקרא DOS-Header והוא נראה כך )מספר 1 בתמונת פורמט ה- :)PE הערה להמשך המאמר: שדות המסומנים בכחול הם שדות שחשובים לנו. לא אוכל לכסות את כלל השדות במאמר זה, לכן אכסה רק את השדות החשובים.
    [Show full text]
  • Assurance Activity
    Assurance Activities Report for Nessus Agent 8.0.0 Version 1.1 4 December 2020 Evaluated By: Leidos Inc. https://www.leidos.com/civil/commercial-cyber/product-compliance Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive Columbia, MD 21046 Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme © 2020 Leidos. All rights reserved The Developer of the TOE: Tenable, Inc. 7021 Columbia Gateway Dr. Columbia, MD 21046 The TOE Evaluation was Sponsored by: Tenable, Inc. 7021 Columbia Gateway Dr. Columbia, MD 21046 Evaluation Personnel: Anthony J. Apted Pascal Patin Allen Sant Furukh Siddique Common Criteria Version: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model, Version 3.1, Revision 5, April 2017. Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 5, April 2017. Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1, Revision 5, April 2017. Common Evaluation Methodology Version: Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, April 2017. Protection Profiles: Protection Profile for Application Software, Version 1.3, 1 March 2019 Functional Package for Transport Layer Security (TLS), Version 1.1, 12 February 2019 Page i of iv © 2020 Leidos. All rights reserved Revision History Version Date Description 0.1 17 February 2020 Initial internal draft 0.2 22 April 2020 Update for modified ST 1.0 30 October 2020 Final version for Check-out 1.1 4 December 2020 Updated for Check-out resubmission Page ii of iv © 2020 Leidos.
    [Show full text]