« first day (1946 days earlier)      last day (3232 days later) » 

06:42
@RoryAlsop, That's why I like my Niva :-)
GOOD SOVIET STEEL COMRADE!
(My dad used to own a soviet era lada station wagon. Prolly the same model they shipped to the UK in the early 90s)
07:15
Morning' DMZ
Morning all
@RoryAlsop
@Jacco - I liked the comedy answer to that one: Avoid driving into water :-)
good you're here
you did just review something
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.
Yup - I was looking at that as well.
The accepted one is out of date, and a link only...
07:19
right
Both are pretty bad and I have the Q in the CV queue
@RoryAlsop Apparently someone watched mythbusters and did the opening the window thing. And it saved their life
Russians flying over American destoryers reminds me of this---> youtube.com/watch?v=ZzQ3eBerHfM
@JourneymanGeek my kids know exactly what to do next time I drive into the river...
"The next time"
phrasing!
07:23
phrasing
PHRASING
Try not to drive like a Kennedy ;)
It looks stupider in bold, for some reason
italic is ideal.
I've done
Language
Once
I always expect that to be followed by the word "Timothy"
(Hope that's the right one - can't watch here)
(someone on root access kept swearing. Tried to defuse it, turns out it was a troll)
I hate that - you put the effort in hoping it's a normal person who just needs calming and it's all for naught
Well, on the bright side
if I suspend someone, they deserve it
Lol - damn right
07:51
:D
@RoryAlsop, I'm back, any progress on the Q?
I see the accepted answer has meta info in it now and collected some downvotes
@RoryAlsop, that's exactly why the Q should be closed - product recs just time out.
maybe it can be deleted altogether.
08:24
@RoryAlsop @JeffFerland or @schroeder - if you're around, I left a redaction in the queue for one of y'all to approve.
09:01
Done @AviD
thanks!
thanks both of you:)
09:27
0
Q: OS X 10.6 and known unpatched vulnerabilities

MatteoApple 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 ...

VTC'd: breaking product
09:42
Not sure it's about breaking a specific product, more opinion based as "what counts as EOLed"
09:53
OP is seeking exploits for OS X 10.6
10:22
silly OP OSX doesn't have exploits
it's an Apple OS
those are invulnerable by definition
haha
@RоryMcCune, I kind of contadicted you here, but then again, it's not the accepted answer;)
@RоryMcCune the sarcasm can be smelled over here
@Lighty here too.
but then again, you are further away from him:)
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.
 
2 hours later…
13:04
I'm not sure I understand the auto comment thing - how does it work?
@RoryAlsop, I added a readme in the meantime. You install the user script and next to comment boxes is a auto button
when you press it, you get a VC-like selection of comments to pick one from to be inserted in the comment box
Chrome plugin?
Thus, you don't have to type out useful comments that are common
That would be very useful
I think there is a chrome plugin, yes
@RoryAlsop, nope, no chrome plugin.
13:10
Ok. Nvm - still looks useful though
there is a firefox plugin, though, and a userscript for tampermonkey
(or greasemonkey, when on firefox)
13:37
@SmokeDispenser i see things i want to change. I will PR you momentarily
or... sometime
sure, go ahead
14:21
Nothing beats bears
:D
that's right :)
@RoryAlsop, have a workplace-upvote:D
14:47
@smo - thanks.
Just got my 2k over there... Still only on user page 6...
15:35
@rory, you're welcome.
also:off of work. see you tomorrow.
16:00
Hmm... I'm from Portland some years ago...
 
5 hours later…
20:58
Joke of the day :
80
A: What's the difference between size_t and int in C++?

Joao da SilvaFrom 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).
Time to not trust linux more than windows…
IMO the popularization of C was one of the worst things that happened to software development.
@CodesInChaos oh really? So what should have been the alternative?
For example Pascal.
Or anything sane, really.
@CodesInChaos What's your beef with C?
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.
21:08
Undefined behaviour, unsafe implicit conversions, array to pointer degradation, C strings,...
The compilation/linking model. Include files really?
What just because it's easy to blow your arm off doesn't mean grenades aren't fun
lol
In fact generally speaking usually the most fun things are also the most dangerous
21:20
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…
@user2284570 no, it isn't
Linux has supported architectures with a 64-bit size_t and 32-bit int for a very long time
nowadays I think a majority of servers and workstations are like that
@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.
@user2284570 yes, there are plenty of ints. So what?
as long as the values they're storing are <2^32, that's ok
@user2284570 yes, but checking is ok
21:34
@Gilles : look at what uses the match_token() function… (just as an example among many)
@user2284570 what about it?
match_number can only parse ints, but it correctly detects if a value is out of range
@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.
21:50
@user2284570 so how about saying what you mean?
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
29022894 : just look line 66.

`len = str_len`
@user2284570 look at line 65
@Gilles : I would personnally would treat the action of automatically mounting a grabbed ꜱᴅ card as userland actions. Just look the filesystem code.
@user2284570 ???
what does this have to do with anything?
@Gilles : if len initial value is unchanged -1 OR something…
@Gilles : that’s how I read it.
@Gilles : it deals with the parsing of unsafe strings withmatch_token().
22:04
@user2284570 oh, yes, that does look wrong, s would typically come from userland so could be >2GB
and if it's between 2GB and 4GB, that sets len to negative, so there's a buffer overflow and a buffer underflow
when did you report it?
@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.
You may want to take the discussion at it’s beginning chat.stackexchange.com/transcript/message/29022029#29022029
22:26
@user2284570 why Google??? Just report the bug and put the CVE ID on your CV
@Gilles : Because it’s the time I don’t spend in causal jobs. My aim is to get security stuff fixed. But not for free.
@user2284570 I don't think bug bounties are a viable career path
put the CVE on your CV and get hired by a security consulting company
and get a clue: don't discuss bugs in a public forum before you've reported them to the maintainers!
@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.
@user2284570 You don't report bugs to the public mailing list! There's a private list for that.
@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.
So first you need to get the bug fixed.
@Gilles : Yes, and for proving I’m the author of the patch, they need to read the discussion which led to it’s merging.
> 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 : doesn’t sound logic… then, they can’t get an electronic way to believe the reporter…
I guess it’s not the first time they would reward someone for the linux kernel. Just need to find how previous rewards in that case were handled.
22:53
@user2284570 that issue sounds like exactly the kind of thing they'd reward someone for... if it's handled properly.
By behaving irresponsibly, you've probably blown it for this time.
Report the bug through proper channels and do the right thing next time.
@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…
@user2284570 It's trivial, but it also finds a ton of false positives. If you've found a genuine issue, report it.
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.

« first day (1946 days earlier)      last day (3232 days later) »