Tag Info

New answers tagged

0

Data tainting was implemented in Netscape JavaScript (navigator 3 and on the server in Enterprise Server) in response to fairly early realizations about the nature of security on the internet. All input coming from the user was considered tainted, unless the flag was cleared, and the taint flag spreads via operations on data (so the result of combining data ...


5

Unfortunately, the bug would not have been prevented, because OpenSSL uses its own memory allocator, rather than the one provided by the system. The buffer from which the infamous heartbeat data is read is allocated by a function called freelist_extract in ssl/s3_both.c. This function, by default, manages OpenSSL's own list of used/unused memory, and does ...


4

I think I can answer this question for the specific case of a crypto library written in Go---it is easy, and not at all hypothetical, because there already is a standalone TLS package, crypto/tls in Go that does not depend on any outside library. Whilst with regard to typical buffer overflows, idiomatic Go is much safer than traditional C, Go offers the ...


12

Actually none of these languages would have prevented the bug, but they would have lessened the consequences. OpenSSL's code is doing something which, from the abstract machine point of view, is nonsensical: it reads more bytes from a buffer than there actually are in a buffer. With C, the read still "works" and returns whatever bytes lingered after the ...


15

If you consider the bug as reading out of bounds of the current structure, than this would probably have been prevented in other languages, because one does not have unbound access to memory and would need to implement these things differently. But I'd rather would classify this bug as missing validation of user input, e.g. it believes that the size sent in ...


2

I will provide you the technical details of the exploit you are talking about and then let you decide yourself whether you should worry or not. The bypassUAC exploit exploits a bug (or rather a feature) of Windows operating systems where processes signed by the Microsoft code signing certificate don't prompt the user when it escalates its privileges to ...


1

UAC Was never ment to be a security measure. Should you worry about it? It depends on what you're doing about it, if you're using the administrator account then yea you should, but if you have the administrator locked with a nice password and you're using a second account then what's to worry about?


0

UAC is not a security boundary, and as such shouldn't be used as a real protective measure. It's nice to have and a neat idea, but it doesn't protect you. Should you worry about it? Sure, why not? A bug is a bug. If you're actually looking to provide real protection then don't run things where UAC has to act -- run as a standard user. Any attack that can ...


0

This is a local exploit. It means someone must already have access to your computer to use it. For a home user this is not a problem on it's own. The same rules for securing your computer still apply: for example don't run .exe files you don't trust.



Top 50 recent answers are included