Blake - this is not an answer. If you can deliver an answer expanding on it - ie why you recommend it, that may be useful. But as it currently stands it will be deleted as a link only answer. — Rory Alsop ♦2 mins ago
Actually, in context of the accepted answer, that might not be worse qualitywise.
Apple is not really know to publish clear end-of-support announcements for their products.
In our network (big university) we have strict policies and we do not allow unmatched systems. We were able to "forbid" Windows XP machines after Microsoft announced the end of support.
We would now like ...
Also, dear DMZ. As a result and in aid of this meta I have authored a compilation of autocomments for Sec.SE. I'd be happy for pings suggesting edits and/or pull requests. I will post a meta in a week from now.
Also, I'd be happy for any feedback
@schroeder, this might be pretty useful especially to you, commenting a lot. I'd be happy to add more, if I missed anything.
From the friendly Wikipedia:
The stdlib.h and stddef.h header files define a datatype called size_t which is used to represent the size of an object. Library functions that take sizes expect them to be of type size_t, and the sizeof operator evaluates to size_t.
The actual type of size_t...
Thank you, I didn’t knew the linux kernel had so many way for kernel side buffer overflow with size_t to int truncation(so much that a single developer can’t write a patch alone).
The underlying mechanism of computers and OSs is very complex and is just difficult to not mess up. I also think that back in the day we weren't security oriented.
Heemmmm can someone help me for this please ? I recognize as a student I have exams and needs to pass driver licence for the first time. The use of int or unsigned int wheressize_tshould be used seems definitely to be the norm in linux kernel. It’s too much work for me. Of course the spend time wouldn’t be lost.
@CodesInChaos : disagree It’s one of the best things to make profit legally.
Several thousands size_t to int truncation is simply too much.
lol… it seems not hardened linux distributions cover this…
@Gilles : lol have you launched a grep for searching unsigned len or int len in the kernel source code before saying this? There’s really many results. about ¼ of them concerns strings.
@Gilles : but… Wait??????!!!!!!! I talked about match_token() because it uses match_one(). checks for the size of strings need to be done by functions that call match_token().
@Gilles : Oui, match_number() n’a pas de problèmes. Mais ce n’est pas de ça dont je parle.
match_one also uses a bunch of int variables, but I don't see one used where a size_t is needed
there's a limit of INT_MAX on the length of each token, I think. It isn't clearly documented.
if your complaint is that kernel functions are badly documented, I agree
that makes them prone to misuse, but the typical usage of match_token is with tokens that come from inside the kernel and that are only a few bytes long
size_t is used for the string that's being parsed, which typically comes from userland
@Gilles : No I’m not aware of a platform that can run little endian code in that case (ᴀᴍᴅ64 runs kernel code only in the first 2GB). The only case I see is ʀꜱ64.
@Gilles : As I said, this issue is widespread and it was only an example among many.
@Gilles : Most of my mates with my qualification level tends to do casual jobs. But I prefer things that I can show on my CV. My plan is create a patch myself that can satisfy Google after being merged. But thousand times is too much : it’s too much work for me. So I didn’t reported it yet. Being alone I won’t do it before a long time.
@Gilles : I agree but the same is true for causal one… I’m still a student and by the time I finish my studies, I’ll get a better job without security parts.
@Gilles : by the way, I’m afraid messages lingers week on the lkmls before getting handled… thus meaning the complete (probable) vulnerabilities list would be public for a long time before getting fixed.
@Gilles : but this a requirement for getting a proof I’m the original finder. by listing Linux in their bounty program. I think Google understand it involve 1ˢᵗ posting on the lkml.
@Gilles : I don’t demonstrate any actual threat like I did for git (as an example). Perhaps there’s not even a way to make a buffer overflow. The scope of the program are security improvements, not exploits.
So they need a link to public mailing list.
The patch should be merged without modifications. So once a maintainer handle my post, things should get done quickly.
> In order to qualify, your patch must first be submitted directly to the maintainers of the project, and you must work with them to have it accepted into the repository without reverts for one month.
> We ask you to respect the time of your fellow volunteers, and strictly adhere to the coding, testing, and submission standards employed for each project.
if you don't first report it to the security list, you aren't respecting the project's standards, so you don't qualify for Google's program
@Gilles : and as I told in the beginning, writing a for loop with ${find ./ -type f}along grep "int len" $i` is very trivial and affects many programs which are parts of their list. You can be sure it was discussed elsewhere by other peoples…
The point is there are no genuine issues. Not even an unproven way to make a buffer overflow. The program doesn’t concerns existing threats but security improvements. This include the cases prone to misuse that are never reachable from user space. The only exceptions are for kernel api and hardware handling. False positives are less than 50% in that case.
Not to mention a change in the linux kernel coding standard need to happen for avoiding this in the future. Something which won’t be discussed privately.
@Gilles : Also it’s not the matter as imply using size_t (you can be sure the patch would be rejected in that case). Defining functions that use specific gcc features for checking overflows on operations is required among testing for each parts.