Is there a length beyond which increasing password length provides no additional security?

The strength of a password is a measure of what it could have been. That's how passwords work: they are something which a given user remembers, but is unknown to outsiders. How much unknown ? That's the tricky point.

If you consider a password consisting of 7 random letters (uppercase and lowercase) and digits, where each sign is chosen randomly, uniformly, and independently of each other, then there are 627 = 3521614606208 possible passwords and they all have the same probability of being chosen; so, for attackers, the best possible strategy is to try them all (no order is better than any other) until a match is found. On average, attackers will try half the space of possible password (hence 1760807303104, in this case) before hitting the right one.

So the strength of a password does not come from what it is, and in particular does not come from its length. The password length has no direct relation to password security. What makes a password strong is its randomness; and that's, strictly speaking, a property of the password generation method, not of the password itself. The indirect relation of length with security is that you need some room to exercise randomness: while a very long password is not necessarily secure, a very short password is necessarily insecure.

Moreover, if you create your password by accumulating randomly chosen elements (random letters, random words...) then randomness is increased by accumulating more of them, as long as they are chosen independently of each other (you don't get more randomness if you repeat four times the same word). In that sense, you may have the impression that length makes strength; but that's an illusion. Randomness makes strength -- and just happens to need space.

How much randomness do you need ? Enough to deter attackers. How many passwords an attacker can try per second depends a lot of the context. If the password is the PIN code for a smart card, then the attacker can try 3 codes, and no more (after 3 wrong PIN, the card locks itself permanently). If the attacker must talk to a Web server for each password try, then he will be able to try as many passwords per second as the server is willing to accept, based on the server CPU power and configuration. If the attacker knows a hash of the password, then he can try as many as he can based on his budget (for a simple hash function, this can range in the billions per second).

For each context, there is a limit to the number of passwords the attacker may try. If his chances of hitting the right password within his budget are too low, the attacker will deem it "not worth the effort", and then you win. You do not need to get more randomness than this point.

Since hash functions have a finite length, there is also another limit beyond which it is useless to increase password randomness, but it is much farther. It is not about collisions, but about preimages. Let's put figures under it. A realistic attacker, with a lot of budget, and faced with a simple hash function, may try up to about 270 potential passwords. We are talking about a budget of some millions of dollars here, and also a rather patient attacker (he will accept to spend a few weeks on that password). There are good reasons why this figure won't raise indefinitely with technological advances. Let's consider that the hash function has an output of n bits (e.g. n = 128 for MD5). The attacker's goal is to find a password which, when hashed, yields a given hash value; he does not need the password which was initially used, just a matching password. He has two attacking strategies:

He can try "potential passwords" that the human user may have come up with.
He can try random passwords until a match is found.

Strategy 1 will have cost P/2 where P is (more or less) the number of potential passwords that the user may have chosen. If P is beyond 271 then that's too expensive for the attacker.

Strategy 2 will have cost 2n-1. If n is greater than 71 then that's too expensive for the attacker.

Even the oldest, most basic hash functions like MD5 have an output size which is more than enough to make strategy 2 unworkable (MD2, MD4, MD5 have output size 128 bits; SHA-1 and RIPEMD-160 offer 160 bits; SHA-256 has 256 bits). In other words, the fixed hash output size could limit security only if it was below 70 bits or so.

For more on the subject of password randomness (often called "entropy"), see this answer. For more on correct ways to do password hashing (in particular, to do slow hashing, with salts to prevent parallel attacks), see that answer.


Write-protection at hardware level for security

Quis custodiet ipsos custodes?
Before I begin, I'd like to explain a bit about the term trust as it is used in an information security context. In infosec, trust often has the opposite meaning of what would seem logical. You want less trust. An untrusted component of a system is good, and the more untrusted components, the better. Trust means reliance. If you trust a component, you rely upon it to be honest, correctly implemented, and secure. If you do not trust a component, it means even compromise or malice will not allow it to do harm to you. In a secure computer, the Trusted Computing Base (TCB) is the sum of trusted code on any given system. The smaller the TCB, the better.
This brings us to the question, who watches the watchmen? In infosec, the highest watchmen are the TCB. The fewer there are, the safer the system. While it is impossible to completely solve this issue, one common effective solution is to implement trust in hardware, which is much harder to tamper with than software. Hardware verifies a small amount of software. This small software verifies larger software, and on and on. This is explained later in this post.
Answering your questions

Is it possible to write-protect BIOS chips at the hardware level, e.g. with a device having a similar form-factor to a BIOS Savior but instead possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the BIOS?

Some older systems required jumpers to be set in order to write to the BIOS. Now days, it's almost always in software. You would want to use a modern computer that supports BootGuard in order to mitigate this. BootGuard runs in the CPU before the BIOS even loads and verifies a digital signature in the BIOS to ensure it has not been tampered with. Boot will only resume if the signature is valid.

Similarly, is it possible to write-protect processors at the hardware level, e.g. with a device having a similar form-factor, mutatis mutandis, to that described above for the BIOS, i.e. sitting physically between the CPU socket on the motherboard and, the CPU itself, and again possessing a hardware switch that physically prevents current from reaching the circuitry capable of overwriting the CPU's firmware?

CPUs do not have firmware. In fact, they have no permanent storage at all. Intel even has a "statement of volatility" in many of their documents, essentially saying that a second-hand CPU will not contain any personal information or permanent changes from its previous owner. For example, from the Xeon E5 v4 datasheet, section 1.1.4 contains the following:
1.1.4   Statement of Volatility (SOV)

        The Intel® Xeon® Processor E5 v4 Product Family does not retain any
        end-user data when powered down and / or the processor is physically
        removed from the socket.

Technically, CPUs do have a small amount of permanent storage called OTP (One-Time-Programmable) fuses, but they are used for permanently changing some basic settings, such as whether or not BootGuard is active. It does not contain anything executable.
You are probably thinking of microcode. Microcode is a way that CPUs can modify the behavior of certain instructions by routing through a microcode table. This is used to fix buggy instructions or even disable them completely. However, it's not built into the CPU, and can only be loaded at runtime. Once a CPU resets, microcode is lost. There are two main ways a CPU can load microcode:

The BIOS, which often contains microcode from the time of manufacture.
Software, which downloads the latest microcode and inserts it.

Microcode is verified using a signing key known only to Intel. To insert malicious microcode, one would have to be in the position to both get you to run it, and to obtain Intel's signing key.

Are there any server OSes/distros designed to support this sort of configuration out of the box?

Tails is specifically designed to do this. It is an amnesic live system that keeps data only in memory. It uses a special type of filesystem called a union to fuse two other filesystems. Specifically, it fuses the read-only squashfs, present on a USB stick or DVD, and an in-memory tmpfs. Any changes to the union filesystem are written to tmpfs. This provides the illusion of one, large, writable filesystem, when in reality there is only one that is never-changing and another that exists only in memory.

Are there any information resources (books, websites) dedicated to deploying and maintaining servers in this fashion?

You may want to look into diskless servers. These are common in clustering and boot over the network. All data they have, unless saved over the network, is lost on reboot.
Other hardware that can be modified
The list of hardware you provided is not exhaustive. There is plenty more on a modern motherboard that can be modified, for example:

Both HDDs and SSDs have writable firmware powering their microcontrollers.
Option ROMs are present in nearly every PCI device and are executed by the BIOS.
GPU firmware is usually not writable over software, but it is not write-protected.

There is more, and unless you have a way to verify your boot process, trying to write-protect everything will be a cat-and-mouse game.
Measured boot
With some effort, even using software (on modern hardware) alone, you may still be able to verify the integrity of your hardware, sharply reducing the number of components you have to trust. It is even possible to do this remotely for a computer you do not have physical access to! This is called remote attestation. Usually, this is done using the TPM.
The TPM is a small hardware component (though often emulated in firmware in newer processors) which is designed to be tamper resistant and secure. It has minimal functionality, and can only do a few things. Primarily, it is used to combine the hashes of various components of the system, and they will unlock (unseal) themselves when the hashes match a known value. Various pieces of software send copies of parts of the system to the TPM to be hashed. As a result, the TPM's hashes will change if any component of the system changes. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system is untrusted.
A TPM verifies several different components of the system and stores in it PCRs. Each PCR has a different purpose, and verifies a different part of the system (taken from another post):
PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all command-line arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used for SRTM

An important thing to remember is that the TPM cannot act on any detected tampering. In fact it is fundamentally not able to, being positioned on the LPC bus. All it can do is verify that the hardware is in a sane state, and refuse to unseal itself otherwise. The sealed data could include a disk encryption key (ensuring the system will not boot if the system has been tampered with), or a secret known only to you and not guessable (and thus not spoofable) by attackers, such as a string (which is how Anti-Evil Maid from ITL works).
The end of this process is that you have reduced the TCB for your entire system down to the small, read-only CRTM, and the secure TPM chip itself.
Resources / pointers
Since you asked for some resources, I would look into the following things for improving improving the security (reducing the trusted computing base) of a COTS workstation:

Measured boot
Remote attestation
Trusted Platform Module (TPM)
Static Root-of-Trust for Measurement (SRTM)
Dynamic Root-of-Trust for Measurement (DRTM)

Some other questions that may be relevant and could help you understand this process:

Anti-Evil Maid - Invisible Things Lab
Trusted Platform Module - Wikipedia
Link
Link
Link
Link
For remotely unlocking LUKS volumes via SSH, how can I verify integrity before sending passphrase?

TL;DR
Write protection is a game of cat-and-mouse. The only practical solution is to use measured boot.


malicious website blocked - on a legit program?

After a quick google search I found THIS and according to them it's fine. mb_warband.exe is known to be published by a legitimate company (Taleworlds Entertainment) so everything should be fine. If this was happening to me I'd treat it as a false positive.


Making a hash function "iterative" already exists; it is called PBKDF2. Bcrypt is still preferable because PBKDF2 can be thoroughly optimized on GPU.

Designing a good password hashing function is a difficult job; but yes, existing hash function are good building elements, so they are likely to be involved at some point. Indeed, look at scrypt: it starts and ends with a PBKDF2 invocation, hence a lot of hashing. But the memory hardness comes from what happens between these two hashing phases. It is not a matter of a simple assemblage of hash functions that would provide memory hardness; just like a car is not simply "wheels that go where you want": the wheels are essential, but there is more in a car than wheels.

Cryptographers are currently busy designing and analysing new password hashing functions that try to be better (in some way) than PBKDF2, bcrypt and scrypt. This is the Password Hashing Competition. Some of the candidates reuse existing hash functions (e.g. Catena), but, like scrypt, their nice "password hashing" properties (e.g. memory hardness) comes from the rest of the design.


Customized approach to protect plaintext passwords/usernames in database table?

As a service provider, You should never, never store passwords in a way that they can be retrieved.  Comparing yourself to an email client is a bad way to think of it, and doesn't take into account an attackers perspective.  Compromising a Thunderbird install only gets an attacker one or a few sets of credentials.  Compromising your service could get an attacker your entire customer bases credentials.

As other commentators have pointed out, you now have the job of protecting the password set.  If that's compromised and DB access is possible, you've now leaked ALL of your customers gmail usernames and passwords.  If you have a lot of customers, this is a gold mine.  Don't underestimate the power of dedicated attackers.

As Stephen Touset points out, you should be using the GMail API, which doesn't reveal passwords, but uses revocable tokens using the OAuth2 framework.  If you were compromised, the tokens could all be revoked.  That's not possible if the attacker were able to get all the username/password combos.


Public key cryptography can, in this case, be used to facilitate setting up a secure channel in which to transmit a symmetric key.  Once the secure channel has been set up, it is not necessary to continue to encrypt and decrypt using the public/private keys.  Instead, generate a symmetric key and use that to encrypt the traffic.  You only have to distribute the symmetric key once, and the traffic need only be encrypted with this key rather than with each public key.  The main challenge is when or if the symmetric key needs to be regenerated, revoked, etc.


Media players (vlc, spotify and windows media player) don't work after a virus attack

The standard advice we give on recovering from a malware infection is "nuke it from orbit". By which we mean wipe the computer, reinstall the Operating System and Software from known good copies (such as a CD or a download from the vendor) and then very carefully restore your data from backup.

The reason this is the standard advice is that modern malware is usually modular. The first bit of malware gets in, and then it installs a range of other pieces of malware. So even if your AV reports that it has removed the original infection it detected, you can't be sure that other malware has been installed that the AV hasn't found.

It might not actually be remaining malware that is causing your current issue (I suspect it more likely that the malware or the AV's cleanup has damaged some files, probably a codec.) But you can only be sure with a complete reinstall of your OS.


Suspicious login alerts vs customer privacy

You have several options:
1. Give users a choice
Ask users if they would like to enable a feature which alerts them when there is a login attempt from a location that is far away from their previous login attempts; and inform them that in order to do so, you will need to save data from where they have logged in.
By disabling this feature by default, you show that you care about your user's privacy and if a user wishes to trade in a potential loss in privacy for potentially higher security, that is their explicit choice.
2. Just use the data you already have
It is not universally agreed on whether IP addresses are personal data or not, so depending on where you are operating, storing a user's previous IP addresses may be possible. However, even under GDPR, you can require users to consent to storing the IP addresses they have used to log into the service.
You can then use the IP addresses to look up which geographic region they belong to. While the level of detail varies somewhere between "this country" or "this part of this city", it's good enough for your purposes. If you know the user keeps logging in from Switzerland, and suddenly you have a login attempt from China, then that is suspicious. It really doesn't matter where exactly in Switzerland, or where exactly in China.
I'm sure there are more options, but I can't really think of any right now that aren't just re-hashes of these ideas.


Why do sandboxing environments not rely on antivirus programs?

The problem is largely in the effectiveness of the dynamic analysis. How do you define malware? What does malware always do that normal programs never do? (Hint: there is no answer to this question)

Well-written malware can look innocent and perfectly legitimate programs can look dangerous.

Here's a simple example: the malware might try to join your computer to a botnet. So the dynamic analysis is looking for new outgoing connections? Well what if it's time-delayed? You won't catch that and you'll still serve it up to the user. So you look for code that will initiate a connection? What if it's a legitimate app that initiates connections to a server?

For almost any example, you can come up with either a way to circumvent detection, or a legitimate use case that would be blocked.

It's more effective to sandbox - to restrict the permissions of components that are likely to be compromised. For instance, don't allow your browser tabs (which are separate processes in something like chrome) to have filesystem access. Even if a tab-process gets compromised, it can't write malicious files to your disk (without prompting you for permissions)


How to convince your boss about importance of IT security

There's several issues here.

Your immediate concern seems to be that you have not managed to convince one individual of the need for better security. Fixing that will solve the problem - but it may be a big mountain to climb. Greg Dolph's answer already covers this.

The problem here is that your employer is producing a product which is not fit for purpose, and may result in serious damage to your employer, to the users of the product, and to other parties. Unless the organisation which employs you is your boss (and does not have other stake holders / share holders), then you should at least be making other key decisions makers aware that you have concerns which your boss thinks are unfounded.

It's commendable that you are concerned with the security of the systems you are working on, and you have taken the first step to resolving the problem. But if this does become more widely known, then it's likely that those responsible for decision making (or possibly even those responsible for enforcing law/policy) will want to be seen to be taking action - i.e. you need to cover your rear. Try to make sure you've got any verbal discussions noted, preferably minuted. Get copies of all emails somewhere you can access them.

Don't threaten. Don't cajole. Keep calm. Be persistent. Keep records.


http://www.cryptool.org/ - free, and have all that you need for educational purposes. I use it in different cryptography trainings.
From their site:

" Numerous classic and modern cryptographic algorithms (encryption and decryption, key generation, secure passwords, authentication, secure protocols, etc.)
 Visualization of several algorithms (Caesar, Enigma, RSA, Diffie-Hellman, digital signatures, AES, etc.)
 Cryptanalysis of several algorithms (Vigenère, RSA, AES, etc.)
 Cryptanalytical measurement methods (entropy, n-grams, autocorrelation, etc.)
 Related auxiliary methods (primality tests, factorization, base64 encoding, etc.)
 Number theory tutorial
 Comprehensive online help
 Accompanying script with additional information about cryptology"


In all of this answer, I am considering the problem of recovering the password (or an equivalent password) from a purloined hash, as stored in a server on which the attacker could gain read access.

The NTLM hash is weak, but not as weak as the older LM hash.

The older LM hash includes several capital weaknesses:

Not case-sensitive.
Limited to 14 characters.
Splits the password in two 7-character halves which are hashed separately.

This last weakness allows for very efficient cracking (regardless of the care taken in choosing the password); see this answer for a some details.

The less-old NTLM is just MD4 computed over the password. This time, the password is case sensitive, and can be quite long. There is some dispute as to the real maximum password length which could apparently be up to 127 characters or so. Since MD4 is computed over UTF-16 encoding of the password, the whole range of Unicode could theoretically be used, but since the user needs to type the password regularly (and without visual feedback), using characters beyond the printable ASCII set is looking for trouble.

What is weak in NTLM hash is that it is unsalted, and that MD4 is fast (MD4 is also cryptographically broken in several ways, but not for raw preimage resistance as is used for password hashing; for that, MD4 is as robust as it ever was). MD4 is actually faster than MD5. A recent GPU will compute several billions of MD4 instances per second. This makes it easy for the attacker to explore vast sets of potential passwords (what is known as a dictionary attack). The only defense is to choose your passwords from an even vaster set.

Let's throw some maths at it: since NTLM is unsalted, a dedicated group of attacker might find it worthwhile to build a big rainbow table. There are various possible optimizations, but, as a rule, things would go like this:

There is a security parameter, called t; that's the average length of a chain in the rainbow table.
If the set of passwords covered by the table has size N, then the storage requirements are about 10*N/t bytes (10 bytes per sorted chain end is a reasonable estimate).
Building the table entails a cost of about 1.7*N hash function invocations.
Attacking one password with the table entails computing about t2 times the hash function, and making t lookups in the table.

If the table is split over a hundred mechanical hard disks, then about 10000 lookups can be done per second. If the attacker is really motivated, he might wish to spend one hour or so per password, which means a maximum t of 3600000 for the lookups (let's say 222); the corresponding CPU cost is down to about 232 hashes per second, which is feasible with a couple recent GPU. The hundred disks allow for 300 TB storage (I am talking about 3 TB disk, which are off-the-shelf today), which brings the possible N to about 267. That's rather huge, but technologically feasible. Our group of attackers could buy a hundred GPU (and a big air conditioning unit) and be done with computing that table within a few months.

So, in order to defeat our motivated adversaries, we need to choose passwords at random from a set bigger than their N. If our set of possible passwords has size more than 277 and our passwords are chosen randomly and uniformly in that set (i.e. the password entropy is 77 bits or more), then the attacker has only 1/1000 chance of cracking a given password with his table. This ought to be sufficient to dissuade him.

How do we get 77 bits of entropy ? If we restrict ourselves to letters (uppercase and lowercase) and digits, so that the password can be typed on arbitrary keyboards, then we can have a little less than 6 bits of entropy per character. Therefore, 13 characters are sufficient. Isn't it swell ? Only 13 ! No need to go to huge passphrases. But mind the small type: that's 13 totally random letters or digits. No question of letting a human choose these characters, or even generating a dozen passwords of 13 characters and letting him choose the one he likes best. You take the generator, you produce one password, and you learn it. The mental effort is the price of using an unsalted fast password hashing mechanism like NTLM.

(Of course, the attacker group described above is realistic. You may want to increase complexity a bit, so that your passwords will also be strong with regards to tomorrow's attackers; so make it 14 or 15 characters to be safer.)


How do I determine where ssh login attempts are coming from?

As Ladadadada said, the IP logged by SSH was indeed the attacking system's address.

I talked with our network guy and he had set up a One-to-One mapping of the AWS instance's IP address to an external IP in our firewall that pointed to our internal server.

192.168.30.36 <-- 123.123.123.123 (our external ip) <-- Internet <-- Amazon IP

He believes that when we released the AWS instance somebody later got a new instance with that same IP.  They used the instance as a gateway for bots to probe the network and happened to find our server.


If you do not know what you are attacking, you have no choice but try out all the tools you have in your arsenal.
If you know more about your target, your attacks can be better targeted and tailored to whatever you want to achive.

For example, if you only know that there is some database behind that login form, you have to try all the possible SQLi's - but if you know the exact version of the webapp, database etc you can skip everything that is not fitting on that.

In addition, you might learn that there is a trivial to exploit vulnerability available and can go straight to the core, without having to probe around.


Nodejs-express: file upload vulnerability with txt files?

A file by itself is not malicious, it is just data. It depends on how it gets used. If a text file gets somehow interpreted in an unexpected context, for example as shell commands, then it can cause harm too. Similar some seemingly malicious code binary does not cause any harm as long as it does not gets executed or loaded as library.
In other words: one need to how the file will be used later before you can decide what filtering and restrictions you need to apply. Your question offers no information in this regard and thus it cannot be answered if text file can be malicious or not.


As with any security related matter it boils down to risk and cost of mitigation. Below are some additional measures you can take, but some will be quite an investment.

This is actually a common problem. Some things you might do to reduce the risk is implementing sessions recorders like Centrify which also limit an administrators access and can re-play what he did. Technical accounts should never be used by administrator unless through a system which established accountability like CyberArk.

Access should be restricted and all logons should be reviewed and audited. Passwords or keys used for database connection should be limited. E.g. only allow the user with the technical account for the database server to connect from the DB's IP. Preferably these are set by the security officer and cannot be viewed by the administrator when inputting it using a two-eye principle.

The most important part here is to make sure people administering the servers are not the same people as the people administering the log collection and analysis servers.

There has to be some level of trust and you can implement several controls to prevent fraud, but in the end it's still these people's job to make the system work. Hampering them is also not beneficial for the adoption of new security measures in place. Detection is still easier to do than prevention and a bit more fool proof because you will always have a trail somewhere. You just need to make sure you can guarantee your log integrity by logging remotely.


Basically, a man-in-the-middle attack could occur.

If someone were to listen in on your users when they submit their username and password, that person would be able to retrieve their login credentials.

Any decent network password sniffer could easily pull this off.


Can I add other key holders to an existing PGP file?

While this would theoretically be possible, the common tools do not support it. PGP has --export-session-key and GnuPG has --show-session-key & --override-session-key, but the latter is only used for decryption. For encryption, a new random session key is generated every time.

--show-session-key
Display the session key used for one message. See
--override-session-key for the counterpart of this option.
We think that Key-Escrow is a Bad Thing; however the user should have
the freedom to decide whether to go to prison or to reveal the content
of one specific message without compromising all messages ever
encrypted for one secret key. DON'T USE IT UNLESS YOU ARE REALLY
FORCED TO DO SO.
--override-session-key string
Don't use the public key but the session key string. The format of
this string is the same as the one printed by --show-session-key.
This option is normally not used but comes handy in case someone
forces you to reveal the content of an encrypted message; using this
option you can do this without handing out the secret key.


Yes and no.  The memory addresses that you see from a process do not directly correspond to the physical (or even virtual) memory.  One of the tasks of the kernel is to map the memory of each process and give that process the illusion that it is the only process running on a machine.

Therefore all processes start their .text (and other parts of code and static libraries) from memory close to 0x0 and their stack starts from the end of the memory.  (That's a actually more complex than that, but it is a decent enough analogy.  Moreover, since malloc() is a system call the kernel will tell the process an out of memory issue no matter how much memory the process sees).  If you start the same process with the same input two times, its memory shall look the same on both starts.

The final mapping between the memory seen by a process and the physical memory is done by the CPU by the use of mapping tables (of which the CPU is told by means of a register).

On the other hand it isn't that easy.  Seeing the problem with the possibility of the overflow using the same memory address stack randomization (ASLR) came into life.  Several Operating Systems today enable stack randomization by default, where the kernel do not start the memory of a process from 0x0 but from a random initial value.  This makes the memory of the process to be shifted by a handful of bytes even when the same process starts two times.

Example

The following trivial program:

#include <stdio.h>

int main(void) {
    int i;
    printf("%p\n", &i);
    return 0;
}

When run on a machine with stack randomization (ASLR) enabled will print distinct addresses, but when I disable it it starts printing the same addresses (assuming the file with the program is named c.c):

[~]$ gcc -o c c.c
[~]$ ./c
0x7ffd52d0aa3c
[~]$ ./c
0x7ffc27da904c
[~]$ sudo echo 0 > /proc/sys/kernel/randomize_va_space
[~]$ ./c
0x7fffffffe86c
[~]$ ./c
0x7fffffffe86c

Extra Note

After testing this on two very similar machines (x86_64 linux 4.8.13) I got exactly the same output from the last two lines.  That is because the program and the kernel are deterministic.

Yet, that may not be the case across very different versions of the kernel.  For example, kernel 2.x will likely produce a different address for i.  This means that the VM where an exploit is developed must mirror the target machine as much as possible (hence the danger of machine fingerprinting).


What is the term to use when logging an event where a user downloads or prints PHI?

RFC 3881 details a format for capturing security audits in healthcare applications.  It is the starting point for audit logs in the DICOM standard and IHE.

In any case, it discusses Export and Import events specifically in the case of printing and creating media. I would stick with the term Export.


Ignoring all the PCI-DSS and legal implications, for your approach to be an efficient deterrent, people need to be able to retrieve the personal information from the videos - if nobody can extract that info then the deterrent doesn't work because no one will be actually able to see that personal info.

However, when people see where it is, they can now remove it or blur it out before sharing the video, making your approach pointless.

Most watermarks out there are designed to be either secret and invisible (security by obscurity is bad but in this case a compromise isn't a major issue) so that people can't remove it and yet the content creator can still decode that watermark in leaked videos to be able to track who was the original uploader, or, they can be extremely visible on purpose making the protected content worthless (like stock photos with the brand name in the center, so they show a sample of the work while not being usable as actual stock photos).

So, either go with the secret watermark route (in which case embedding an unique user ID is enough for you to track down the user without exposing personal data), or go with the big "in your face" watermark in which case no personal data is needed either because the watermark makes the media unusable, so you're not actually loosing anything by leaking unwatchable media.

Finally, have you considered making it so that people don't have to steal your stuff? Affordable pricing, great UX, no DRM nor other BS like geo-blocking would make your service quite a good investment.


Does hiding php error messages increase security of the web app?

You should never allow end users to gain insights into the inner workings of your system.
Doing so will allow a potential attacker to streamline his attacks and increase the chance that they will be successful.

For more information have a look at this:
https://cwe.mitre.org/data/definitions/200.html


Lost user password in Slackware 14.1, how to resolve encryption in /etc/shadow?

Unfortunately for you, it is not encryption, but a one way hash, so there is no way to actually reverse it. The only option you have is the brute force route, where you guess passwords and hash them until one matches.

There are tools which do this, like John the Ripper, or you can go down the route of rainbow tables, which effectively have the brute forcing done for you, but it can take a while.


Next generation is just marketing lingo and "IDS" itself too, as do IPS, NGFW, UTM and whatever they come up with next week. The underlying technologies got several enhancements in the past, e.g. they can look deeper, may use anomaly detection etc - but in my opinion they are still dumb enough and can still be circumvented with not too much efforts.

Don't let you blend from all the marketing claims about 100s or 1000s of applications they can detect or how fast they are and how secure they are. They give you some protection, but not the advertised one.

And in case you don't believe me but the marketing guys you can read here:

"Evading Deep Packet Inspection for Fun and Shell" (BlackHat 2013): https://media.blackhat.com/us-13/US-13-Opi-Evading-Deep-Inspection-for-Fun-and-Shell-WP.pdf
Circumventing security systems with uncommon HTTP: http://noxxi.de/research.html (disclaimer: that's my research)
NSS Labs Report from 02/2013, where you can see how far claimed performance and security differs from the real world: https://www.nsslabs.com/reports/2013-firewall-comparative-analysis-tco


Can serving HTTPS to Internet Explorer on Windows XP be made secure?

Fast answer

No!

Acceptable workaround

Even an HTTPS connection from IE or Windows XP can't be considered as
secured by a normal and even a skilled user. It was a known weak combination long before Microsoft announced its support deadline.

Hence I would suggest a 2 steps approach for a webserver architect.

Detect the referer, and if it is IE any version or XP any version,
 redirect client toward a web page indicating that you identified he is connecting from a computing environmnet which is known as unsecure.
Clearly assert you can't be hold responsible for any spy upon his connection which might occur at the level of his computer and his choosen software.
Ask him if he accepts the risk involved and want to proceed with an
 insecure connection even with the infamous small lock which might be displayed, even with your server URL starting with https:// and even with the high grade certificates you installed on your web server. Upon explicit agreement from the user, redirect him toward the core of your webserver through HTTPS. Upon disagreement, congratulate him for making a good choice and hope to see him back soon within an environment of full trust.

This will be a correct communication informing your customers and at the same time offering them a chance to brain storm and improve, one day, their security :).


Server-side encryption mechanism (Nextcloud)

Say we have an asymmetric key pair, where public key A can be stored freely and private key B is encrypted. For each file's encryption, there is a symmetric key K(file). K(file) is encrypted by public key A and can be decrypted by private key B only.

The key point here, I think, is that you can use different passcodes to decrypt private key B, similar to LUKS encryption. For example, key C (the real key for decrypting key B), has several copies and each one is encrypted by your passcode or one of your app-passwords. In this case, your passcode and your app-passwords have no difference in decrypting files.


Are payment card PINs safe to send via SMS?

Am I right in believing this security could be improved, and would my suggestion of >using SMS for one-time codes and the (HTTPS) banking web app to show PINs, offer better >overall security?

Yes, I believe you're right on. A better schema would be to send a one-time-code via SMS and to reveal the PIN via HTTPS (or even better, not reveal the PIN at all once it has been set). As well, the bank should recommend that users change their PIN upon receipt.


How to know if accessing to a VPN service is safe and won't steal my data

I don't think you can. In theory VPN can be set up as full proxy, so all traffic can be inspected. This is setup setting and usually as a user you can't really "detect" if the VPN provider is doing this or not.

You shouldn't trust ANY VPN service provider.


Would 'spam' mail really avoid eavesdropping?

It would help if you elaborated on if you are defending from a targeted attack or just being cautious, and what vector the potential adversary would be using to eavesdrop.

That being said, the method you are referring to is called 'security through obscurity', and is

  "… discouraged and not recommended by standards bodies."

I would say that is putting it nicely. Security though obscurity is very BAD (on it's own).

Try watching this video from Def Con 21, told from the perspective of forensic investigators. They show several examples of why security through obscurity is a bad idea. You can also get an understanding of the capabilities of the tools used by forensic investigators.


How does the attestation mechanism of U2F guarantee the provenance of the key material?

The U2F spec overview says:

  The intention is that the public keys of all the 'Attestation' key pairs used by each vendor will be available in the public domain - this could be implemented by certificates chaining to a root public key or literally as a list. We will work within FIDO to decide the details on how certified vendors can publish their attestation public keys.

In practice most key vendors provide a root certificate somewhere that you can use to verify the attestation certificate. This works just like any other PKI.

Each authenticor contains an attestation private key that is used to create attestation signatures, and the associated attestation certificate that is sent as part of each registration the authenticator is used for. The attestation private key will be shared by at least 100,000 authenticators to prevent services from identifying an individual based on the attestation key. The purpose is to provide a way to prove which vendor manufactured the key, as the private key should be impossible to extract from the authenticator, and is thus known only to the vendor.

The registration response message includes an attestation certificate and a signature. The attestation certificate is a normal DER encoded X.509 certificate, and the signature is created with the attestation private key over the rest of the response message and part of the associated request.

To properly verify the attestation, first the attestation public key is extracted from the certificate and used to verify the signature of the response. Without this step, an attacker could simply take the attestation certificate from a known to be accepted authenticator and use it instead of their own device's attestation certificate.

After the response signature has been verified (tying the attestation certificate to the registration keypair), the attestation certificate itself must be verified. As an example, here is the certificate from one of my keys, decoded with the openssl x509 CLI:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 618376000 (0x24dbab40)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Yubico U2F Root CA Serial 457200631
        Validity
            Not Before: Aug  1 00:00:00 2014 GMT
            Not After : Sep  4 00:00:00 2050 GMT
        Subject: CN = Yubico U2F EE Serial 13503277888
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:02:b0:94:be:34:7d:47:79:41:c4:77:8e:be:c5:
                    ca:4d:ed:2a:47:9f:aa:1e:6f:ec:39:af:eb:de:0c:
                    20:70:cb:5b:d4:bd:69:c9:6a:78:e3:bf:87:51:fe:
                    b5:79:1b:8d:fa:ca:c2:94:01:75:1c:b1:57:b9:7c:
                    09:e4:39:1a:36
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            1.3.6.1.4.1.41482.1.1:

    Signature Algorithm: sha256WithRSAEncryption
         a3:63:ae:0e:98:3a:f3:0b:ba:f1:2c:8b:2d:f3:5a:59:bf:1c:
         bb:4a:1b:0f:cb:68:c4:84:55:84:90:f6:87:34:58:65:b8:db:
         02:69:c3:46:e5:53:88:4c:2c:56:07:af:0e:a2:7b:90:ac:8c:
         f1:ef:43:1f:72:ac:18:9d:b2:1c:82:49:14:bf:17:88:a5:51:
         1a:33:d0:7b:4c:8e:34:64:7c:e9:f6:1e:15:16:a9:a9:b3:6e:
         90:0a:40:20:61:f6:9a:a4:6e:12:c5:32:b9:93:f9:42:3e:fa:
         aa:4c:f9:a3:b6:54:b4:dd:de:f2:92:4a:54:8f:d5:99:95:51:
         0d:d4:f7:f4:d9:a4:d5:21:93:87:3c:71:c9:b8:7e:86:85:3e:
         9e:2d:a7:5e:8f:0c:6d:28:30:53:74:d4:ef:dd:5e:14:96:f8:
         c3:39:06:10:7b:d6:8b:d6:35:0d:aa:d2:c3:78:11:ec:a3:ca:
         43:bc:93:0b:73:40:97:de:f6:9d:68:8d:94:55:0c:4c:fb:18:
         a9:e2:4b:86:a2:e5:d8:8f:49:98:99:a0:9b:ce:5b:81:0c:53:
         6c:af:39:0d:c8:bd:de:96:0d:f3:30:ca:ca:bc:05:21:a1:83:
         23:95:7f:fe:bc:a5:9c:a9:0b:20:b1:0d:09:b5:23:1c:58:c2:
         7e:ba:67:83

The issuing certificate can be determined from the Issuer field, in this case it's Yubico's U2F Root CA. Assuming the application trusts that CA, it would take the public key from that root certificate (the root certificate itself would come from a list of trusted roots) and use it to verify the signature on the attestation certificate. If the verification is successful, the registration keypair will be cryptographically tied to the attestation certificate, and the attestation certificate will be cryptographically tied to the trusted root.

If you trust that the vendor has manufactured their authenticators properly so that the attestation private key and the key wrapping secret (or key storage depending on design) cannot be extracted, then you can be confident that the registered key is from an authenticator created by the vendor you obtained the root certificate from.


Can I add a password to an existing private key?

A word of caution: as stated in laverya's answer openssl encrypts the key in a way that (depending on your threat model) is probably not good enough any more.

Of course you can add/remove a passphrase at a later time.

add one (assuming it was an rsa key, else use dsa)

openssl rsa -aes256 -in your.key -out your.encrypted.key
mv your.encrypted.key your.key
chmod 600 your.key

the -aes256 tells openssl to encrypt the key with AES256.

As ArianFaurtosh has correctly pointed out: For the encryption algorithm you can use aes128, aes192, aes256, camellia128, camellia192, camellia256, des (which you definitely should avoid), des3 or idea
remove it

openssl rsa -in your.key -out your.open.key

you will be asked for your passphrase one last time
by omitting the -aes256 you tell openssl to not encrypt the output.

mv your.open.key your.key
chmod 600 your.key


Should a Mobile app able to check what password is locally saved via a user facing feature?

In addition, what a lot of people do is, if the user types in a wrong password x times in a timespan of x minutes, it gets denied for x seconds/minutes.

For example:

John enters a wrong password 5 times in one minute, thus he cannot log in for another 2 minutes.

Or even better, if the app NEEDS an internet connection with user accounts and such, you can even lock it after 5 times in 2 minutes (for example!), and let it be unlocked via email (companies use email a lot, if this app is for business-type users, most of them would have their mail on the same device as the application).


Why does Windows allow non-parent processes to read/write the memory of a process?

The Windows (and, for that matter, Linux) security model generally holds that everything a user (in the "login account" sense) does is done at the same trust level. In other words, any two processes running with an identical security token are trusted exactly the same amount. If one process can access its own memory (which of course it can), so can the other.

If an attacker has arbitrary code execution on your account, it's already game over. Even if you don't let them access the memory of current processes, they can launch processes themselves under a debugger, overwrite scripts/libraries/executables stored in user-writable locations (such as your login/shell resource scripts), read or write all the data that a program running as you would have access to, and so on. In other words, there's very little value in creating a security boundary between a user's processes.

Now consider the advantages of not doing so. You don't need to be admin/root to debug a running process, which might be in a weird state that would be hard to re-create. You can write tools that modify or extend the functionality of programs installed in non-user-writable locations (this is heavily used in game modding, for example). Basically, you - the user - have more control over the software running on your session, and you can do it without needing elevated privileges. The only cost is that there are a few new ways that somebody an attacker running code as you can hurt you, and at that point, they don't really need any more.

Windows' Process objects do have ACLs, which can be used to do things like give another user access to your process' memory or allow certain access (such as the ability to tell when the process exits) without other access (such as the ability to write to the memory). You could also restrict the access to a process from its own user - the same way you can restrict access to a file you own - but the owner of any object can overwrite its ACL so another process also running as you could just overwrite that restriction (again, like marking a file you own "read-only").

In general, if you want to ensure other processes cannot tamper with a process you launched, you need to launch it as another user. There's a few ways to do this, such as CreateProcessWithLogon or creating a Windows Service. The Win32 API does not provide an equivalent of the "setuid" bit on a file, but a privileged service account can emulate that behavior. If you want to restrict what an app can do, you can easily create a low-privilege version of your own security token with CreateRestrictedToken and then create a sandboxed process using it (an open-source example of this is the Chrome sandbox on Windows).


How can common users defend against the StageFright vulnerability?

You should disable the automated downloading of media files through SMS/MMS, there are multiple services that use this. Depending on which you use, you should disable this in the settings per service you use.

For google messenger:

More can be found here.

Besides that, don't open any messages containing multimedia files from someone you don't know or trust as you can still download the file manually and trigger the file that way.

Note that the SMS/MMS part is not the real threat here, it's just a way of getting malicious media files onto your phone and getting them to execute without user input. The actual threat is in the way media files are being processed. So receiving & viewing a media file through other channels will be just as dangerous.


Can opening a Word document reveal user's IP address?

Yes there are also other ways to do this as well.

What you are referring too is adding an invisible digital signature using your own certificate authority and tracking the signature checks. More information on signing a document with an invisible signature can be found here but again you'll also need to setup your own CA and monitor it's traffic:

https://support.office.com/en-us/article/Add-or-remove-a-digital-signature-in-Office-files-70d26dc9-be10-46f1-8efa-719c8b3f1a2d

Other ways this can happen occur when people leverage the scripting function within the document to make a call to a unique URL or DNS request to a unique host either or which then reveals the person who opens the documents publicly accessible external IP address. These can be embedded in different document types in a number of different ways and there are many commercial services which offer software just to do this. Likewise there are many penetration testing tools / red team exploitation tools for Word and other document types (.pdf's are more commonly exploited because these can in some cases also give an attacker a remote shell on the system where the document was opened).

https://www.intralinks.com/products/information-rights-management

http://arstechnica.com/security/2012/05/doctrackr-file-tracking-for-paranoid-people-by-paranoid-people/

https://www.immunityinc.com/products/canvas/

Can this be prevented. Yes but not easily you have to really lock your internal computers security down well and either have tight egress rules which don't allow traffic out or block the IP address(es) the documents want to call home too.


How general should a vulnerability be to be eligible for a CVE?

From the CVE FAQ:

  An information security vulnerability is a mistake in software that
  can be directly used by a hacker to gain access to a system or
  network. See the Terminology page for a complete explanation of how
  this term is used on the CVE Web site.

  The intention of CVE is to be comprehensive with respect to all
  publicly known vulnerabilities and exposures. While CVE is designed to
  contain mature information, our primary focus is on identifying
  vulnerabilities and exposures that are detected by security tools and
  any new problems that become public.

If an individual website was breached, it is unlikely that the website owners will make publicly known. If they did make the details public, and it only affected their own proprietary software, it would be of little value to the public. If the vulnerability was in software used and produced by some vendor (open or closed), then its likely it could be come a CVE.

If a website is breached, that might not be the result of a CVE type attack, but maybe the more generic Common Weakness Enumeration (CWE). For example, if a site was breached by SQL injection or XSS, the specific string would not likely be a CVE, but could be classified under the CWE.

If you are looking for details of specific website attacks, you would want to look for breach reporting, such as the Privacy Right's Clearinghouse's Data Breach List.

The best way to test this would be to try to submit your find and see what the CVE community wants to do with it in their review process.


Pen tester revealing users information for company

I believe it is okay to hand out user information as long as it is clearly related to the user's work in the company and to the company's security. I as an employer would like to know if there are employees which use weak passwords, etc. because this clearly affects the security of the corporate IT.
Social media accounts of users have clearly nothing to do with the user's work at the company. The fact that you work at company X doesn't authorize your manager at company X to hack your facebook account, pretty much like it doesn't authorize your manager to break into your appartment and see what you are doing there.
There is a grey area, though, which I believe is pretty relevant: If users use the same passwords for the business and their personal accounts then this can be relevant for the company's security and I as a responsible would want to know about that. Therefore I can understand why you were asked to also hack the social media accounts, even if it is more than obvious that this is not the correct way to address this problem.


Does a session time out make an app more secure in a A+ HTTPS / random session key?

Session timeout can prevent or mitigate several types of attacks. The following come to mind.

Unsecured workstation.  Boss leaves his desk for lunch, employee sits down and gives himself a raise.

Shared devices. Donald Trump uses a complimentary iPad at the Mar-a-la-go Resort.  Terrorist is able to obtain iPad afterward. Obtains nuclear codes.

Brute force.  FREAK attack downgrades SSL/TLS encryption to 512-bit; server farm containing 1,000 PS-4 gamestations cracks the key in  just over 31 minutes.
 Only those sites with a 30-minute session timeout escape catastrophe.

Session identifier theft.  Odd Job Trojan infects browsers all over the world and sends session keys to one hacker located in Hoboken, New Jersey.  Hacker has all the time in the world to sift through the harvested keys and use them for nefarious purposes. Some of the keys will no longer work by the time he gets to them-- those with session timeouts.

CSRF.  Hacker sends out a million emails with a funny GIF that links to https://www.wellsfargo.com/Transfer.aspx?ToAccount=1234&Amount=100000.   Of the one million email recipients, 10,000 open them.  Of those, 100 are still logged into Wellsfargo because their session timeout is too long.  Hacker gets millions of $$$, retires in Costa Rica, where he now passes time by posting on Stack Exchange.

If you don't implement session timeout, you are more vulnerable to all of the above sorts of attacks.  Using an HTTPS connection and/or using a crytopgraphically random session identifier are good and important steps, but neither of those saved anyone in the attacks above.

Only you can decide if the risk of the above attacks is important enough to offset the additional inconvenience to the end user. If it's just a social app, maybe not. If it's a banking app, almost certainly yes.


The primary things you can do are:

Use SSL sitewide.  Disable HTTP (non-SSL) access, or redirect users to the SSL version of the web site.
Use HSTS to declare to clients that they should only connect via SSL.
Make sure that all cookies have the secure flag set.  This will ensure that your user's browsers will only send those cookies back over SSL-protected connections and never disclose them over any non-SSL (HTTP) link.
Add your site to Chrome's hard-coded list of HSTS sites (the HSTS preloaded list).
Add your site's public key to Chrome's public-key pinning list, if they'll let you.
Check that your SSL server is properly configured, using standard SSL configuration checkers: e.g., SSL Labs.
Make sure that your certificate is valid.
Consider buying an Extended Validation (EV) certificate.  You could also mention somewhere in the support section of your site that you encourage users to check for the green glow in their address bar every time they visit your site.  (Probably this won't be highly effective, but it might help a little bit.)
Consider providing a link to Chrome and HTTPS Everywhere on your web site somewhere.
Configure your web server to defend against the BEAST attack.  Enabling TLS 1.2 is a good idea, but you may also want to choose carefully the preference order of algorithms, to help protect users whose browsers don't yet support TLS 1.2 (which will be essentially all of them right now).
If you provide access via IMAP, make sure you only support IMAPS (the SSL-enabled version), not the cleartext IMAP.
Enable STARTTLS on your SMTP server.
Avoid use of third-party Javascript widgets (e.g., libraries, widgets, like buttons, etc.).  Don't load external content over http.

I would not try to avoid use of Javascript.  I especially would not try to block access to users who have Javascript enabled.  That is a usability disaster, for little or no security gain.

See also Guidance for implementors of HTTPS-only sites (Server side).


Is asymmetric encryption vulnerable to man-in-the-middle attacks?

Asymmetric encryption provides security for messages exchanged between Alice and Bob only insofar as Alice knows Bob's public key and Bob knows Alice's public key. Otherwise, attackers could publish fake public keys and, in effect, pose as Alice when talking to Bob and vice versa.

An historical view of the issue is the following: in older times (say, 50 years ago), Alice and Bob could have talked "securely" only if they knew an initial shared secret. If both Alice and Bob know a shared secret K, then they can use it to encrypt their messages and also to check their integrity (with a MAC). Encryption is against passive attackers (who try to learn the message contents) and MAC is against active attackers (who try to alter the message contents). For a complete secure flow, Alice and Bob would also have to include some sort of numbering in the messages, so that dropped, duplicated or reordered messages are detected.

An initial shared secret is usually hard to establish. Especially when there are more than two Alices and Bobs. If there are n people who must securely talk to each other (securely against external attackers but also against the n-2 other users), then there will be a need for n(n-1)/2 shared secrets, and each user will have to store n-1 secret values (one for each other user to which he may want to talk to).

Asymmetric cryptography makes the problem easier (but not easy). With public/private key pairs, each user stores one private key, and just needs to know the public keys of the other n-1 participants. Public keys are, as the name says, public. They can be shown to the whole world without any ill effect. Presumably, distributing public elements is easier than distributing secrets, because only active attackers are to be feared.

The analogy is that of the Wall. Imagine that there is, in some specific place (say, the central plaza of a town), a big wall made of marble. Everybody can come and look at the wall. On the wall are engraved the public keys of Alice, Bob, Charlie, Dave, Ebenezer,... so that everybody can learn these keys without fear of interference. The whole is guarded and only the official town engraver can add or remove or modify a public key on the wall; and he will engrave, say, Fred's public key only if Fred himself shows him the said key and some valid ID (driver's licence...).

A big wall can be inconvenient, especially for users who do not live in the town where the Wall is located. To allow for remote operation, a nice scheme has been designed: the official engraver is also given a camera, a printer, and a stamp. When the engraver has finished engraving a new public key, he takes a photo of it, prints it a few times, and signs them (with the official stamp). Now, if Alice sends to Bob such a photo, Bob may trust that he has a genuine copy of the part of the Wall which contains Alice's public key: we assume, here, that the engraver's stamp cannot be counterfeited. It is not a problem if some bad guy opens letters and sees that photo: it is public anyway. Making sure that the stamp cannot be counterfeited may prove troublesome, though.

Here comes the really nifty part, which turns this photo business into a complete public-key infrastructure. Instead of a stamp, the official engraver will use a digital signature: the engraver also has a public key, engraved on the Wall too. If Bob knows the engraver's public key, then he can verify any signature computed by the engraver over any photo. That way, by knowing a priori a single public key (the engraver's public key), he can make sure whether any given photo is genuine or not, allowing him to learn the public key of just any other user.

In normal PKI terminology, the photos are the certificates and the engraver is the Certification Authority. Bob must still start somewhere, i.e. know a public key, but only one (the "root") and for an unlimited number of users; it will even work for user's public which do not exist yet. In a full-blown PKI, there may be too many users for a single engraver to manage them all, in which case we can extend the principle with a Master of all Engravers who signs the public keys of subordinate engravers. The Master is then the "root CA" or "trust anchor", and the subordinate engravers are "intermediate CA". To avoid abuse, the photo of the public key for a subordinate engraver is duly marked as "this is the public key of someone who can act as engraver".

Ultimately, once the system with photos works, nobody actually comes to look at the Wall anymore. Only the photos and the signatures are used, and they are sufficient. We may then avoid building the Wall itself (marble is expensive, after all); the "engraver" simply writes down the public key on a piece of paper, duplicates it, and signs the copies directly.

The PKI model explained above is what is done on the Web, with X.509 certificates. Each Web browser (or operating system) knows a priori a few dozens of root public keys, from which the validity of the certificates for the millions of existing HTTPS-powered Web site can be ascertained by verifying the signatures on them. This is a very centralized model; it is called a hierarchical PKI.

Other models exist, in particular the Web of Trust. In the WoT, everybody can act as an "engraver". Since Bob cannot assume that every single user is as trustworthy and reliable as an official engraver, Bob will accept a given public key as being Alice's only if Alice can show many certificates for that key; i.e. Alice could convince Charlie, Dave and Ebenezer that a given key was indeed hers, and Bob happens to know the public keys of these three guys. In that sense, the WoT is more heuristic in nature than a hierarchical PKI. In fact, this is a matter of a definition of identity: in the Wall model, Alice is Alice because she was given an ID card from some "authority" (say, a central state); in the WoT, Alice is Alice because sufficiently many other people know her as "Alice".

The definition of identity is crucial. What does it mean, that Alice and Bob want to "talk securely" ? Bob wants to talk to the "real Bob" which means that she has a preexisting notion of who Bob is, and what makes Bob distinct from, say, Charlie. If Bob is a complete stranger, then it makes no sense to want to talk to Bob exclusively; there is no "Bob" distinct from "Charlie". This notion of identity is what will dictate what kind of PKI you need. If identities come from a centralized structure, then a hierarchical PKI is appropriate. If identities come from mob approval, then a WoT is the right model.

Or maybe you don't want a PKI at all, after all. For instance, Bob may be, from Alice point of view, "the guy who knows the secret password P". Then we are back to the historical setup which predates asymmetric cryptography. We can still do some advanced science, though. Passwords are poor keys because they tend to be guessable through what is known as a dictionary attack. If Alice and Bob just use P as encryption key, then spies may record the message, then try to decrypt them with potential passwords. In order to fix that issue, Password Authenticated Key Exchange algorithm can be used. With a PAKE protocol, Alice and Bob authenticate each other with regards to their common knowledge of P, but a sufficient amount of asymmetric cryptography was injected in the protocol to prevent spies from learning any data which they could use to test a potential password. If Charlie wants to try a potential password P', then he will have to talk to Alice (posing as a fake Bob) or to Bob (posing as a fake Alice), and he will have to do it again for each P' he wants to test. Surely, after a few such failed attempts, Alice and/or Bob will notice that something is amiss. This is how PAKE protocols allow the secure use of low-entropy secrets (i.e. passwords) without needing any kind of PKI.


I suppose you are talking about a SSL context: rogue CA is trusted by some client to validate the certificate issued to a SSL server.

The rogue CA can create a fake certificate and private key, to be used to impersonate the server. The client will believe that it talks to the genuine server, but in fact it talks to the impersonator. If the impersonator, simultaneously, connects to the true sever as if he was the client, this becomes a Man-in-the-Middle attack. Client and server notice nothing, but the attacker sees everything, and can alter data at will.

Data decryption and forward secrecy are relatively unrelated to that point. In a PKI, the CA does not normally see the servers' private keys. When a server owner wishes to obtain an "SSL certificate" for his server, he generates a new key pair locally and sends only the public key to the CA. Since the CA never sees the private key, it cannot use it to decrypt recorded connections, regardless of whether the cipher suite enables forward secrecy (i.e. a "DHE" cipher suite) or not. The role of the CA is to guarantee the ownership of public keys; if the client really uses the true server's public key, then the cryptography protects the connection, rogue CA or not rogue CA.

However, there are existing CA who are on the habit of generating servers' private keys themselves. They send to their customers the certificate and the private key together (usually as a PKCS#12 archive -- aka "pfx file"). They do that because it is simpler: many server administrators, with limited competence at what they do, have trouble handling private keys and certificates when the key pair was generated within their Web browser, on their desktop machine (not on their server). When the CA is rogue and generates the private key for the server, then it can keep a copy of the private key and use it to try to decrypt the data. In that case, forward secrecy will be a problem for that eavesdropping rogue CA: use of a DHE cipher suite will force the rogue CA to go to the trouble of running a fake server.

Since MitM attacks are still quite feasible, a rogue CA is a huge problem, and use of forward secrecy is not an adequate mitigation.


Trusted CA SSL certificates and embedded devices

It actually does not matter for the question if the trust anchor is a publicly trust root CA, a locally trusted root CA or a locally trusted server certificate. What matters instead how to deal with the situation when the trust anchor should not be trusted anymore.

A simple approach would be to have a trust anchor which is valid forever. This is the way you are trying to go and it could be implemented the following way: let an arbitrary public CA issue and later renew the server certificates but use the same fixed key pair for each of the server certificates. Then pin to the servers fixed public key in your device. This way the device will be happy with verification since it only checks the expected public key. Browsers will be happy too since the certificate was issued by a CA they trust.

Only, what happens if the servers key gets compromised? This is a similar situation you face if your trust is based on a public root CA and the CA expired. In both cases your trust anchor should no longer be trusted. Thus you need to somehow switch to a new trust anchor.

If you've pinned against the servers key you might have an alternative key pre-created and put into the device which is used in case first key was compromised. On certificate verification you then check against this alternative key if verification fails with the primary key. If this succeeds you know that the primary key is considered obsolete and should never be used again for verification. You could also have multiple alternative keys so that you could obsolete more keys over time.

Still, no key should be trusted forever since with the time the chance increases that the key got compromised or got too weak. So you very likely need to have some way to update the software in your device. This is usually needed for bug fixes anyway but could also be used to bring new trust anchors to the device, no matter if these trust anchors are new trusted root CA's or trusted server keys.


How is Malware Traced to a Specific Country?

Entity resolution and just general intelligence is a large part of it.

When we encounter malware and reverse it and find Cyrillic characters or other indicators that the attacker is, say, Russian, and the C+C calls out to IP address A.B.C.D, it gets noted. Every bit of information we learn about a campaign gets logged in in intelligence repository of some kind. Some of this information gets shared with other institutions or sourced through third-party intelligence vendors. We learn from them, they learn from us about what threats exist.

Then later on, we may see new malware pop up. This time, they did a better job removing linguistic identifiers from the code so we don't have any starting hints as to the origin environment. But we observe that it calls out to similar domains as this other piece of malware we saw, or it too reaches out to A.B.C.D (which indicates shared infrastructure). Or it reaches out to a domain name registered to a name we've seen pop up in other campaigns.

The IP geolocation itself is usually a red herring, as most traffic gets routed through botnets or Tor. However the fact that two unique pieces of malware may reach out to the same location (regardless of what it is) does indicate commonality between the campaigns, so we correlate that with the information we already know about existing attacks.

Similarities in code are also usually a red herring; much malware is classified as 'commodity' malware which means anybody who knows where to find it can just buy it 'off the shelf' so to speak. So if I write something to steal money from Swiss banks, I can sell it to the Russian mafia, some Israeli teenager, or a Chinese government actor all the same-- now all three of them appear to be using code with linguistic hints of America/Canada/UK as the source.

Also, amusingly enough, many governments look the other way when it comes to hacking institutions in foreign countries. When we see malware that specifically does not target a given country, it's generally an indicator that the source itself is that country-- no Russian wants to get caught hacking a domestic bank when there's literally no consequence if they just do it to an American bank instead.


It can't be protected completely, but that is not the purpose of the shadow stack. The shadow stack prevents modification of stack by a buffer overflow in local variable (variable on stack), not by arbitrary code. If the attacker already can execute arbitrary code, it is game over.


Is denying login after incorrect attempts ineffective?

Preventing login without the right password is the core functionality of the login process. Just keeping on doing that is by no means an "additional" security feature.

Denying login attempts after X incorrect attempts means rejecting all attempts in that situation, regardless of the value of the password which is then presented. If you still accept the right password, then you are not denying anything, you are just managing a login process.

With online systems, disabling the account is a bit rash; it means that anybody can effectively block your account by entering junk passwords. A smoother procedure is to add delays: after X incorrect passwords, have the server block the account for, say, one minute, and reblock it for one minute after every attempt until the right password is entered. The initial X attempts should be enough to cope with users with shaky fingers, and the one-per-minute rate severely impedes a bruteforcing attacker (coupled with some safety measures such as banning IPs from which too many login request come in too little time).


Could emulating a virtual environment stop some malware from infecting the system?
Yes. Also, creating fake VM artifacts is not the only way to stop malware from executing. You could also create fake mutex objects or certain registry keys that malware oftentimes creates in order to avoid re-infecting the same machine. And there are a lot of other ways, depending on the malware's internal workings.
Would it be a good prevention strategy?
Not really. It would be a false sense of security. Assuming the malware even has any anti-VM measures in place at all and cares to halt execution if a VM is detected (which many don't), there are still thousands of ways malware can check if it's inside a VM or not, and every malware differs. There are hundreds of millions of malware programs out there, all of which work differently, and to spend your time on all of them would not only be a massive undertaking but would still likely prove to be an unreliable defense against malware.
So no, it would not be a good prevention strategy. Your time and effort would be better spent elsewhere, such as focusing your threat model around preventing actual execution of the malware at all by using good security practices, enforcing code signing, hardening your system, reducing attack vectors, keeping everything updated, not downloading anything suspicious, etc., and you should be ok, and have no need for this prevention strategy.


sensitive assets identified and properly protected

The government uses C, S, and TS as the general material level restriction, but to think that's all they use would be a gross over simplification. Other things in play are "Need to Know" policies -- basically, just because you have TS clearance doesn't mean you get to access everything marked TS. There are far too many to list here, but basically it means that you end up with a greater level of complexity than a simple three marking system.

As for small businesses, classify information based on potential damage if released to the public. Would the firm be embarrassed? Would their competitors gain insight into how they run their company? Is it a secret formula that is behind the entire company? You must also consider legal repercussions from releasing protected information (medical records, etc).

So, the answer your question: companies usually must have at least a confidential level to protect employee information. There is nothing to stop a company that feels it needs additional categories from making them. In every day life however, most firms forgo the "C/S/TS" idea and just use compartments of information.

For example, Apple may not classify their employees in levels of trust (they may, I have no idea), but they certainly compartmentalize project information to only the needed departments.

Think of the government's method on one end of the spectrum and a mafia's "web of trust" on the other. There is more than one way to skin a cat. A company is going to pick the one with the "hopefully" best risk-to-reward.


OpenSSL 1.0.1t does not decrypt with -bf if encrypted with OpenSSL version 1.1.0e

The default digest used for generating the key from the password changed in OpenSSL 1.1.0. In versions prior to that md5 was used - which is now considered insecure. In OpenSSL 1.1.0 the default digest is sha256.

In order to decrypt a file in OpenSSL 1.0.1t generated by OpenSSL 1.1.0 you should add "-md sha256" to your command line arguments. If that is not possible then you can also force OpenSSL 1.1.0 to use md5 as its digest by adding "-md md5" to the encryption command line arguments. This is obviously insecure but should work.


Can I get a malware on Windows without administrative rights?

Yes. It can infect you nonetheless.

Using a non-administrative account only keeps malware from spreading to other users in the system, and it's a good practice regardless of everything else.

But aside from that, The malware can do everything your user is allowed to do, because it is a program like every other: it could create and modify files, open sockets, log your Keys, post malicious content on your social network profile, spam your contact list..

Then, there is privilege escalation: a bug in a piece of software, a misconfigured service, or any known or yet-to-be-known vulnerability in windows could elevate the malware privileges to administrative, just like it happens on unix systems.


Authenticated Diffie Hellman Key Exchange

Your description is a bit confused and appears to be wrong. In particular, we see Alice computing here Diffie-Hellman half gKA and then proceed to send... her Diffie-Hellman secret KA to Bob, which is not at all what she should do.

Plain Diffie-Hellman works the following way:

Alice generates (randomly) her secret KA and computes gKA.
Bob generates (randomly) his secret KB and computes gKB.
Alice sends gKA to Bob.
Bob sends gKB to Alice.
Alice computes (gKB)KA, using her secret KA and the value sent by Bob.
Bob computes (gKA)KB, using his secret KB and the value sent by Alice.

By the magic of mathematics, Alice and Bob ends up with the same value, which is the shared secret that they thereafter use for whatever cryptography they need to talk to each other.

For the authenticated variant, the same computations are done; but Alice and Bob also own asymmetric key pairs usable for digital signatures, and they use them: Alice signs whatever she sends to Bob, and Bob verifies that signature (using Alice's public key). Similarly, Bob signs what he sends to Alice, and Alice verifies that signature (using Bob's public key).

Note that a no point whatsoever does Alice send KA (he "DH secret") to Bob in any form. Neither does Bob send KB to Alice. And there is no encryption anywhere. You may encounter many tutorials that purport to explain digital signatures in terms of encryption (usually as "encryption with the private key"). These explanation are remnants of older times (the late 1970s, in fact, in the original Disco era) and are, in fact, plain wrong and very confusing. So don't think in those terms. Signatures are signatures, encryption is encryption.

Authenticated DH is what is done in, for instance, in SSL/TLS with the "DHE" cipher suites. It is also what happens in SSH (version 2).

There are two main reasons for using such an "ephemeral" Diffie-Hellman ("ephemeral" because Alice and Bob generate their DH secrets KA and KB on the fly):

The "permanent" key pairs owned by Alice and Bob may be unfit for anything else than signatures. A source of confusion (again) is that there is not one algorithm called RSA; there are at least two, one for encryption and one for signatures, and they appear to be able to use the same kind of key pairs. However, even if a RSA key pair can be used both for encryption and signatures, there are good reasons not to do so. There are also other signature algorithms (e.g. ECDSA) whose keys cannot be used (at least not easily) for encryption.
Using ephemeral DH secrets provides Forward Secrecy, which is good. Namely, the permanent keys of Alice and Bob must be stored somewhere; so they could, potentially, be stolen afterwards. With simple RSA-based key exchange (no DH, Alice encrypts a random session key with Bob's public key and Bob decrypts it), the ulterior key thief could use it to decrypt a past session. With the DH and the signatures, this issue does not occur; even if Alice's and Bob's signature private keys are revealed afterwards, their past communications cannot be decrypted. The whole concept of forward secrecy revolves around the idea that the "DH secrets", being generated on-the-fly, kept in RAM only, and destroyed immediately after completion of the DH key exchange, are immune to ulterior theft.


Is there a utility you would use to create wordlists from directories and files?

You can use crunch for that:

-q filename.txt Tells  crunch  to  read  filename.txt  and  permute
what is read.  This is like the -p option except it gets the input
from file ‐name.txt

crunch manual


Do I really need all these Certificate Authorities in my browser or in my keychain?

The Web is worldwide. That you are a "US user" does not mean that you will only look at US websites.

You can remove any CA certificate that you do not wish to trust. That's your prerogative. The only consequence of removing a CA certificate is that the machine will cease to automatically accept as valid any certificate issued by the said CA. Translation: some HTTPS Web site may begin to trigger scary warnings, which you can always bypass, but which are scary nonetheless (and training yourself to bypass scary warnings might not be a good idea anyway).

The truth is that, as a user, you have very little information on which you could base your decision of trusting or not trusting any particular CA. Ideally, you would trust only those CA for which you can establish a clear responsibility path down to you: the CA which will give you a lot of money in case you get swindled due to a mistake made by the CA. However, there is no such CA. Instead, what you have is a list of "default CA" who made a deal with the OS vendor (Apple, in the case of Mac OS) so that the OS vendor accepts to include them as "default CA". These CA, and Apple, are way too smart, legally speaking, to give you money in case of any problem (as a Mac user, your money relationship with Apple rather flows in the other direction). Yet, if one of the "default CA" begins to behave improperly, that's Apple public image which is at stake.

So my advice would be to let things as they are. This is what almost everybody does. Remember that, in any case, the point of the CA is to validate the certificate, which does not mean that the corresponding site is maintained by honest and trustworthy people; the only thing that the CA guarantees is that the Web page you are looking at really came from the Web site whose name is in the URL bar.


A buffer is a pre-allocated area of memory where you store your data while you're processing it. Basically it's just saying that from a certain address in memory until memory address + x Bytes is reserved to allocate data. In C this is often called an array.

A buffer overflow happens when you assign more data than can fit into the buffer and overwriting the code beyond memory address + x. You might have done this before and you will notice that your program crashes. Now the problem is that somewhere beyond your buffer is the return address (this is pointing to the next instruction that will be executed after assigning the buffer and loading the data into it) and if you overwrite it with random data your program will crash. However if you manage to load byte code (this is a compiled program which the CPU can directly execute) and you can actually make it point to your program, then you can execute code on that machine.

Now you might think that this is not really an issue if you are running it locally, but imagine programs like SSH or FTP servers which run on the internet or imagine a restricted environment where certain programs run with elevated privileges. If you were able to execute code within the context and privileges of the other program, you could be able to break out of your restrictions or take over a remote server.

If you want to know more about assembly, bufferoverflows and shellcode, I suggest buying the Shellcoder's Handbook. It's THE book to learn this stuff.


A VPN works by tunnelling connections initiated by your PC through the VPN, so that they come out on the Internet at the VPN endpoint and not at your PC's primary Internet access point. This happens at the IP level, there is no difference between HTTP and HTTPS in this regard. So the behavior you describe indicates that your HTTPS traffic is not going through your VPN, i.e. your VPN setup is misconfigured.

If you want all traffic to go through your VPN (except obviously for the VPN tunnel), it's best to configure it at the IP routing level: make sure your default route goes through the VPN and only the VPN entry point is routed through your Internet gateway. If you've set up a VPN only for web access through a proxy setting, make sure to activate it for HTTPS as well as HTTP.


Whenever an unhandled exception somehow makes it into production, is it safe, viable, etc. to print an encrypted stack trace to the end user?

Think about why you want to do this. It is in my opinion, entirely pointless.

If the exception occurred on the server side, handle and log it there. There is absolutely no point in displaying the stack trace to the user.

If the exception occurred on the client side, in a thick client style web app, desktop app, mobile app etc, there is absolutely no point in encrypting it. Any determined enough user can decompile or reverse engineer client side code. In fact, how would you encrypt the data? Encryption implies an encryption key, and this key has to be stored somewhere.

I also question what a normal user can do when you display the stack trace. If crash data is important information, implement some sort of reporting functionality for diagnostics.


Encrypted volume vs password manager - security benefits

This may not completely answer your question, but I have tried both encrypted volumes (OS X) and password management systems (both KeePass and mSecure) and there are some security advantages to the latter, as you suggest: related to usability. They're minor, and one might even be viewed as a disadvantage.

The password managers may permit you to not "show" passwords on the screen, but instead let you copy and paste them without having them be visible.
In password managers, even when passwords are visible, only one is visible at a time.
Password managers facilitate the sharing of the encrypted password database between devices (this might be viewed as a disadvantage, but it also might mean you don't have to read a password on one device to use it on another, and that you have backups of your password).

These things are mostly trivial, compared to more important questions:

Where are the passwords stored?
How are they encrypted?
How are the keys managed?

I haven't been able to find out good answers to these questions yet for the most recent version of mSecure, so I haven't upgraded yet.

EDIT: Another advantage is auto-lock on inactivity. mSecure will automatically lock itself after a configurable amount of time.


Is my vendor vulnerable to sql injection?

I haven't worked with payroll systems and I don't know how old the one you have is.  I do know that they often have to support ancient data formats so it could be that they need to do this for compatibility.  Even so, this is indicative of a flawed system and a company that does not have the resources to fix their software.  It does not immediately follow that it is vulnerable to SQL injection.  It is worth checking out, though.

It is written into the contracts we have with vendors that they allow a security assessment if we want to.

My advice is to ask them for documentation of their security assessments and if you are not satisfied, then tell them you need to do your own security assessment.  Unless they've hired an outside firm and have a complete report (longer than a page, say), and can show a history of assessments and improvements, then you probably shouldn't be satisfied.  Then you can hire someone to do it or do it yourself if you feel comfortable doing that.


Slowloris DOS partial request with subsequent headers?

As pointed out in the comments, there is in fact a degree of variability amongst different servers.  I was wrong to assume the connection timeout wasn't reset when sending subsequent headers.

I've implemented a basic Slowloris with nodejs here, and tested it against Ubuntu Apache2 (2.4.18-2ubuntu4.1) to prove this.

I tuned the Timeout variable down from 300 to 10 seconds for this test.  After doing this, Apache reported many 408 Request Timeout errors in the error log if the interval set for sending subsequent headers was greater-than 10 seconds (line 54).  By reducing this interval to less-than or equal to 10 seconds, Apache infrequently, if ever, reported any timeout errors.


Why does Outlook not block spam sent by employees?

Intra-domain emails (emails from your domain to someone else in your domain) have a much higher trust score, so they tend not to get blocked. This is done because legitimate employee-to-employee emails can look a lot like spam ("check out these pictures of my cat! [link]") . This is an ease of use issue.

The sensitivity level of this can be changed on the server admin panel. But test it out to see if it impacts your normal flow of business.

Exchange Online Spam filter policies


Is there a down side to how so many security products bundle multiple components into one these days?

Here are some to think about, mainly from the "home user" perspective. The enterprise environment is unlikely to use a single vendor for all security needs. If they do, the setup and support package usually eliminates all common mistakes.

Good:

More integration/less administrative work to do - you only have one
purchase to make, and one vendor to call for support.
Consistent User Experience - the commands/GUI should be similar, so it should be
easier to learn, while making fewer mistakes.
Pricing is usually cheaper for product "bundles".
Fewer conflicts. Products from the same vendor are less likely to conflict with each other, compared to a similar set of features from programs by different vendors.

Bad:

Single point of failure - especially for "home user" scenarios: if your subscription ends, or if there is a fault, you (may) lose several layers of protection.
Product quality (maybe)- an AV vendor may not necessarily be good at creating a firewall product.
Incomplete configuration - e.g. someone may complete proper config of the anti-spam feature only, mistakenly thinking that configuration across all products has been completed.


Is this a web attack I should be concerned about - trying to enter code for form vars

There seems to be a good answer here and here.

1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

If we simplyfy the above we can get an idea of what's going on:

declare @q varchar(8000)
select @q = 0x57414954464F522044454C4159202730303A30303A313527
exec(@q)
--

Line 1: Declares the q variable as a varchar with 8000 chars.
Line 2: Assignes the encoded string to the q variable.
Line 3: Executes the q variable.
Line 4: Comments out the rest of the injected query.

According to 2 the 0x57414954464F522044454C4159202730303A30303A313527 string is WAITFOR DELAY '00:00:15' hex-encoded. A timed Blind SQL injection attack technique which tells the server to wait 15 seconds before responding. Once the payload is injected, if the server takes 15 seconds to respond, there is a good chance it is vulnerable to SQL Injection. This can be further checked by increasing the DELAY time.


What is the best way to get OWASP ZAP to fuzz parameters with real data?

The best option is to proxy requests that use real data through ZAP. These could be unit tests or something as simple as command line calls to curl. You can also make calls to the target system using the ZAP API.

The Form Handler add-on also allows you to specify values for individual fields, but I dont think this handles URL parameters.


How serious is a local virus in terms of network security

There's two possible states I can think of:

The AV caught it on 'entry', stopped it, removed it, and logged it, at which point there's nothing else for anybody to really do
The AV just now noticed something that's been present for a while, so you're already 'compromised'; potentially, any data could have already been exfiltrated, and there's nothing to do but check the logs.  Analysis of the logs could take a while, can be done remotely, and would include checks of other resources (say, network connections) that likely have higher priority.


How to protect Windows Registery from being changed or from programs trying to add keys

In very simple words,
Windows Registry is used by other applications to store user/system specfic data to be used by application.
Q1&Q2(Answered together): Unless you are continuously monitoring your system, there is not practical way to determin if your programs has made registry changes. You can specifically use tools like procmon, regmon to monitor a specific app.
Secondly, if you are a non-admin you should always be allowed to change HKCU registry, because legit programs will also use registry keys under that hive. Theoretically , if you are concerned about any registry key in particular you can always allow or deny permission using ACL.
To explain with an example:
If a software/malware want to maintain persistance by launching at every user logon, it might add entry into the key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run to launch itself. Click here for more info !
However, hypothetically you can set permission for a particular key and then deny the non-admin user the permission for the key. For the above example , this image will provide a better clarity

Q3. Various methods like WMI notification, Event viewer for monitoring all the time. Procmon and regedit can by used to monitor registry changes over a specific period of time.


How bad is a source code leak for an antivirus?

I'm not certain this is necessarily security through obscurity by design. Symantec, like many corporate entities before them, see their source code as the intellectual property and not necessarily guarded for the sole reason of protecting their product from directed attacks.  (Note that it doesn't hurt to have a little security by obscurity as long as it isn't your only means of protection.)

However, with that said, having their (old) source code read can open up new avenues for exploits.  Although it is 5 years old, it is entirely possible (and generally probable) that parts of the source code have been reused in many of their more recent products.

Personally, I have reviewed -- as part of my job -- source code for products which have been in iterations for the past 10 years or more.  The latest editions almost always have at least some code from their initial versions because it is usually the case that the core simply gets augmented rather than re-written.


Is there some kind of a local DoS against processes?

Strictly speaking, what you are asking about is a Fork Bomb.

  ... wherein a process continually replicates itself to deplete
  available system resources, causing resource starvation and slowing or
  crashing the system.

In Windows (because you ask about that OS specifically) you cannot spawn new forks at the OS level, but you can create a cascade of new processes. That technique still falls under the "Fork Bomb" term.