flat assembler
Message board for the users of flat assembler.

Index > Heap > Vista and Internet Explorer security rendered useless

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
drhowarddrfine



Joined: 10 Jul 2007
Posts: 535
drhowarddrfine
r22 wrote:

@drhowarddrfine
I seriously hope you are joking around. If not, I'd like to take my time-machine and come visit you in the 1980s we can debate how punch cards make programs more secure Very Happy Very Happy Very Happy
Another bonehead comment by someone who probably has never seen Unix much less be able to spell it. Someone who still thinks we all use dot-matrix printers and tty machines. Another person who knows nothing of the subject because there's no answer on his Windows machine to tell him what to think.
Post 12 Aug 2008, 01:32
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:
And what do apps have to do with the OS? Still, you don't have to fork. And threads run great.
You're mixing apps and OS yourself... but what's the connection? Mentality. *u*x mentality is fork(), and that's what most server programs are still using. And just how long did it take for linux to adopt proper threading? How long has NT had proper threading? Smile

User/Group is ancient & insufficient, ACL and fine-grained permissions rock. Progress is being made in linux and bsd, but it's still "not there yet" and feels pretty bolted-on, rather than being properly integrated.

But whatever. If you want to spread disinformation about how "insecure" NT is, go ahead. The people who have been running public servers with several years of uptime might laugh a bit at you, though Smile

Oh, and you forgot to comment on ArsTechnica's debunking of the "OMFG GAME OVER" crap. And if you look at it, you'll realize that it's partly flash and java that are responsible for the flaws, and that the attack on address-space location randomization will probably work for other 32-bit operating systems as well.
Post 12 Aug 2008, 09:56
View user's profile Send private message Visit poster's website Reply with quote
drhowarddrfine



Joined: 10 Jul 2007
Posts: 535
drhowarddrfine
f0dder wrote:
Quote:
And what do apps have to do with the OS? Still, you don't have to fork. And threads run great.
You're mixing apps and OS yourself... but what's the connection? Mentality. *u*x mentality is fork(), and that's what most server programs are still using.
Not true in all cases but a Unix fork is as fast/faster than threading, particularly Windows threading in case you hadn't heard. Are you also reading all the articles about threading being a bad thing to do anyway?
Quote:
And just how long did it take for linux to adopt proper threading? How long has NT had proper threading? Smile
This is typical of Windows point/clickers to divert the subject off a Windows flaw into something about 'nix.
Quote:

User/Group is ancient & insufficient,
Why? Because it's been around a long time? The fact that it works better than anything Windows does doesn't matter?quote] ACL and fine-grained permissions rock. Progress is being made in linux and bsd, but it's still "not there yet" and feels pretty bolted-on, rather than being properly integrated.[/quote]EVERYTHING in Windows is bolted on so don't go there. Why do you think MS is throwing it out the window in a few years? But what experience do you have with these to say that? From what you've said earlier, you don't sound like any expert.
Quote:

But whatever. If you want to spread disinformation about how "insecure" NT is, go ahead. The people who have been running public servers with several years of uptime might laugh a bit at you, though Smile
I'm only spreading an article about a security conference report issued by VMWare and IBM to which Microsoft is not denying yet. If you feel that group of four is spreading disinformation, take it up with them.
Quote:

Oh, and you forgot to comment on ArsTechnica's debunking of the "OMFG GAME OVER" crap. And if you look at it, you'll realize that it's partly flash and java that are responsible for the flaws, and that the attack on address-space location randomization will probably work for other 32-bit operating systems as well.
So do you only get partial infections? Does any of that matter? And you say "probably work for others" yet no one said that. They said "might" but no one knows and it hasn't been tried or tested.

See, again, rather than focus on the problem, you try and blame it on everyone else.

For those who think 'nix is all about the command line
Post 12 Aug 2008, 14:27
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
drhowarddrfine: Are you sure you understand what this talk was about? Please read it's whitepaper ( http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf ) and reconsider claims you have made about this research.
Post 12 Aug 2008, 14:51
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

Not true in all cases but a Unix fork is as fast/faster than threading, particularly Windows threading in case you hadn't heard.

From where your heard it? (both parts)

And about ACLs, is it possible that you don't hear when f0dder says that ACLs is also in current development on Linux (at least)?

Do you want me to split this thread into two? (Suggest a name for the new thread in that case)

BTW, I found a bit of aggression from your part drhowarddrfine, even though the others reply to you without offenses (like stupid (or was retard?), bonehead, point/clicker, etc). Please be a little bit patient and explain technically why do you think what you say in the places where you insult.
Post 12 Aug 2008, 14:55
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
drhowarddrfine wrote:
Not true in all cases but a Unix fork is as fast/faster than threading, particularly Windows threading in case you hadn't heard. Are you also reading all the articles about threading being a bad thing to do anyway?
Bullshit. This was the argument people used for not implementing proper threading, but do you have any idea what the overhead of fork() is compared to creating a thread? Sure, copy-on-write can be pretty efficient, but you still have to create new pagetables, cloning handle tables, and obviously you get an extra thread too. So this means with fork() you get the overhead of a thread and the additional overhead of an extra process...

drhowarddrfine wrote:
EVERYTHING in Windows is bolted on so don't go there.
Clutching a straws, are you?

drhowarddrfine wrote:
I'm only spreading an article about a security conference report issued by VMWare and IBM to which Microsoft is not denying yet. If you feel that group of four is spreading disinformation, take it up with them.
The link you originally pasted is spreading sensationalist disinformation and hysteria. I didn't watch the presentation itself, so I can't say whether the two researchers did that too, or only the people who wrote about it on news sites.

drhowarddrfine wrote:
So do you only get partial infections? Does any of that matter? And you say "probably work for others" yet no one said that. They said "might" but no one knows and it hasn't been tried or tested.
Read the Ars Technica breakdown. I'm not sure you have the necessary knowledge to understand what it's all about, but they do a pretty good job at explaining what it's all about. Basically DEP (the per-page non-execute stuff designed to mitigate (but not stop!) buffer-overflows) is defeated because of faulty plugins like JAVA and Flash (and programs opting out... firefox apparantly does that). So DEP itself isn't really defeated, and it has never been meant as a stop-all, only a mitigating factor.

Then there's the defeating of ASLR, Address space layout randomization. This is, again, another mitigating technique, that isn't meant as a stop-all. The tecnique used to defeat Vista's ASLR sounds like it could be applied generally to other systems' ASLR (oh, those systems that have it - it's not at all default on *u*x, unless you're running a distro with SELinux or the like applied).

Of course it's bad enough that a couple of mitigating factors can be worked around, but they still haven't broked IE's sandbox or Vista's UAC... which means if you run an out-of-box Vista install without disabling UAC, you aren't going to be infected.

Dunno if the ASLR thing can be fixed, except by moving to 64bit, but the DEP definitely can. We probably aren't going to see SUN fix up their lame JVM though, and Adobe fixing up flash is unlikely as well - I mean, there still isn't even a 64bit build of flash. But of course, it's Microsoft's fault that those companies write bad code. And it's going to be Microsoft's fault when that bad code gets linux owned as well, right?

For what it's worth, I did my first FreeBSD install... dunno if it was late 90s or very start of 2000's. I ended up deciding that linux did a better job for my server needs though, and I've been through a lot of different distros. I still have the manual from the RedHat 5.1 I bought, and I've been through Debian, Slackware, Archlinux, K/X/Ubuntu, Centos and Gentoo. Probably missed a few. But obviously I haven't gotten any experience from all that, I'm just a point-and-click windows user. *rolls eyes*
Post 12 Aug 2008, 15:59
View user's profile Send private message Visit poster's website Reply with quote
drhowarddrfine



Joined: 10 Jul 2007
Posts: 535
drhowarddrfine
I just found out the articles do not link to the paper. Here it is
Post 12 Aug 2008, 17:49
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Yes, vid posted it four posts up
Post 12 Aug 2008, 17:58
View user's profile Send private message Reply with quote
drhowarddrfine



Joined: 10 Jul 2007
Posts: 535
drhowarddrfine
f0dder wrote:
Bullshit. This was the argument people used for not implementing proper threading, but do you have any idea what the overhead of fork() is compared to creating a thread?
Overhead for forking is the same or less than threading, at least in FreeBSD; don't recall about Linux. You are living in the past. If I have time I'll find the docs.
Post 12 Aug 2008, 20:11
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
With the little I've found seems that clone() does not exists on FreeBSD but exist rfork() instead which allows you to specify which resources will be shared via flags. rfork() it is like clone() but with one parameter only (and maybe a some few differences I've overlooked).

Quote:
Overhead for forking is the same or less than threading,
I wonder if taking more overhead for threading is possible without doing it on purpose.Question

Looking forward for the docs, do you have a link with the Windows' threading comparison too? I would like to see why Windows threads slower than fork().

http://insecure.org/sploits/bsd.4.4.rfork.html (It is the first thing readable that Google found with "FreeBSD rfork", I'm not posting the link as a kind of lame FreeBSD insecurity demonstration in case it looks like it).
Post 12 Aug 2008, 20:56
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
drhowarddrfine wrote:
Overhead for forking is the same or less than threading, at least in FreeBSD; don't recall about Linux. You are living in the past. If I have time I'll find the docs.
If that's the case, FreeBSD's threading implementation must suck. And considering that BSD generally has good code quality, I sincerely doubt this. Threading did suck somewhat in previous FreeBSD versions, especially since the kernel had some big monolithic locks, but the last few versions have made a lot of good progress on eliminating that, and FreeBSD 6.x looks very promising.

I think you might not have followed up with the times, and are confusing modern times with the olden days where threading was emulated with clone() - that was messy.

There's simply no way a clone() is going to be more efficient than native threading, unless your threading sucks, or you have an insecure process model. Giving parameters specifying what to share with a clone helps, but it's still more overhead.

Also, one thing is the overhead of processes/threads (*u*x processes might very well be more lighweight than NT processes, but I don't know enough about that to comment on it... but saying *u*x processes are more lightweight than NT threads is plain silly). Another thing is how it effects the concurrrency model. With separate processes, if you need any kind of inter-thread communication, you need to resort to sockets, pipes, or shared memory (plus some synchronization). Threads in a single process address space can communicate more efficiently...
Post 12 Aug 2008, 22:23
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

the olden days where threading was emulated with clone() - that was messy.

Yes, seems that clone() is not the way anymore Confused

If someone has Assembly code that use native threading (e.g. no clone() nor fork()), please post it.
Post 12 Aug 2008, 22:42
View user's profile Send private message Reply with quote
dap



Joined: 01 Dec 2007
Posts: 61
Location: Belgium
dap
f0dder wrote:
Threading did suck somewhat in previous FreeBSD versions, especially since the kernel had some big monolithic locks, but the last few versions have made a lot of good progress on eliminating that, and FreeBSD 6.x looks very promising.

Current release is 7.0. Exclamation
http://www.freebsd.org/smp/

_________________
(French only) http://dap.developpez.com
Post 12 Aug 2008, 23:31
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
dap wrote:
f0dder wrote:
Threading did suck somewhat in previous FreeBSD versions, especially since the kernel had some big monolithic locks, but the last few versions have made a lot of good progress on eliminating that, and FreeBSD 6.x looks very promising.

Current release is 7.0. Exclamation
http://www.freebsd.org/smp/
Yup, but IIRC it's with FreeBSD 6.x they started making really good progress Smile

_________________
Image - carpe noctem
Post 12 Aug 2008, 23:39
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
f0dder, apparently pthreads_create still uses clone(). Thanks to strace utility I was able to conduct the tests. The system call clone() however may be different from the older days because if I'm right this one has more parameters.

I'm attaching a C source that I found somewhere and modified to see the system calls better. If anyone has the possibility of testing this on other systems than Linux please do it and tell the results.

[edit]I forgot to comment, my "gconf GNU_LIBPTHREAD_VERSION" is "NPTL 2.3.6"[/edit]


Description:
Download
Filename: pthreads.tar.gz
Filesize: 2.51 KB
Downloaded: 88 Time(s)

Post 13 Aug 2008, 20:14
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.