The aging foundation of Certificate Authorities shows yet another crack as security experts are caught unaware
The Palinopsia Bug
Is your VirtualBox reading your E-Mail? Reconstruction of FrameBuffers from VRAM
This document describes a method of reading and displaying previously used framebuffers from a variety of popular graphics cards. In all 4 tested laptops the content of the VRAM was not erased upon reboot. It is also possible to show that the content of the host VRAM can be accessed from a VirtualBox guest, thereby leaking possibly confidential information from a trusted host into an untrusted guest machine.
via The Palinopsia Bug.
The OneRNG is an Open Hardware, Open Source, simple and verifiable USB-connected source of entropy; we do not ask you to “trust” us, we give you the ability to verify for yourself that the OneRNG does what we claim, and that it does nothing else.
The Gostcrypt project has been launched at the end of 2013 as fork of the (late) Truecrypt project. Snowden’s leaks have made clear more than ever that the massive use of encryption by citizens must become a reality. This is possible only if there is a vast, rich offer of trusted, open source products like Truecrypt, with the strong support of the hacker community. However, at that time we did not foresee the unprecedented upheaval of terrible shock with the recent Truecrypt disappearance. More than ever we all need more and more projects to replace it. Gostcrypt is one among (we hope) many others. The variety and richness of encryption solutions is THE solution.
But with Gostcrypt, we intend to go farther than ever. Since the late 70s, most of the algorithms used (not to say all) are UKUSA encryption systems that have been chosen, promoted and standardized under the control of the USA and its minions. It is more than likely that among the different levels of control, mathematical trapdoors are part of the game. We thus decided to used strong encryption systems (as far as we know and despite a few recent “manipulation papers” that have nothing to do with science and which are mistaken operational security with fantasy and which have been rejected recently again as non valid [Babenko & Maro, 2014]) which moreover were not invasive as UKUSA ciphers are (mostly AES) by now. The Gost cipher and hash functions are not everywhere, have not invaded our systems and have been designed by the former USSR for its own need. Aside the fact that it is indeed a very strong cipher (when correctly implemented and a suitable key management), this feature of non-aggressive technological expansion is a key point. GOST algorithms have never sought to spread and to impose on anyone. It has even been rejected from the ISO standardization process in 2012 as a consequence of fallacious, non-reproducible allegations of weakness.
Whatever may be the quality and features of a security project, it can be valid in the long run with trust only. Trust is only possible with open source code and above all with the active support of the hacking community, which will analyze the security, report bugs, make comments and contribute to the project. So welcome on board to everybody.
Top 10 Secure Coding Practices
Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05].
Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws.
Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.
Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.
Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75].
Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75].
Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.
Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05].
Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05].
Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.
Bonus Secure Coding Practices
Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated.
Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases [Swiderski 04].
The following rules and guidelines are specific only to the Android platform. These do not apply to the development of Java or C programs for non-Android platforms. (The full set of Android -relevant rules and guidelines are here.) The term sensitive incorporates the Java glossary definition of sensitive data, as well as the Android concept of permission-protected.
DRD00-J. Do not store sensitive information on external storage (SD card) unless encrypted first
DRD01-J. Limit the accessibility of an app’s sensitive content provider
DRD02-J. Do not allow WebView to access sensitive local resource through file scheme
DRD03-J. Do not broadcast sensitive information using an implicit intent
DRD04-J. Do not log sensitive information
DRD05-J. Do not grant URI permissions on implicit intents
DRD06-J. Do not act on malicious intents
DRD07-J. Protect exported services with strong permissions
DRD08-J. Always canonicalize a URL received by a content provider
DRD09-J: Restrict access to sensitive activities
DRD10-J. Do not release apps that are debuggable
DRD11-J. Ensure that sensitive data is kept secure
DRD12-J. Do not trust data that is world writable
DRD14-J. Check that a calling app has appropriate permissions before responding
DRD15-J. Consider privacy concerns when using Geolocation API
DRD16-J. Explicitly define the exported attribute for private components
DRD17-J. Do not use the Android cryptographic security provider encryption default for AES
DRD18-J. Do not use the default behavior in a cryptographic library if it does not use recommended practices
DRD19-J. Properly verify server certificate on SSL/TLS