Back to singing my same old song:
You DO realize that much of this goofy hacking the kernel stuff is actively
prevented on 64-bit Windows systems, right?
Peter
OSR
Alberto Moreira wrote:
Actually, if code and data didn’t share the same physical memory, a
great stride forward would have been taken as far as security is
concerned. It bothers me immensely that Intel put such an enormous
amount of security-oriented functionality into the i386 architecture,
and, well, nobody uses any of it. Consider: if a buffer overflow is
just that, a buffer overflow, and it is impossible to realize a set of
instructions out of it because that’s not the code segment nor is it
aliased to a code segment, it can be pretty hard to insert anything
through a back door. So, the way I think it should be is, trusted code
in Ring 0, I/O in Ring 1 (no, dudes, I/O is *not* trusted code nor
should it be treated as such), Services in Ring 2 and Applications in
Ring 3. But no, Risc is better, no ? Heck, one gets what one pays for.
Yes. Oddly enough, in many ways Win16 was a more secure environment
than Win32, because Win16 used segmentation extensively.
Of course, Windows 3.x didn’t prevent an application from creating a new
data selector aliased to the code segment, but that would have been
pretty easy to fix.
–
- Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sooner it(64bit) comes to mass, better it is. Just a very honest opinion
from the dark side of goofy …
-pro
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola
(OSR)
Sent: Wednesday, March 23, 2005 8:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Converting MDL from NonPagedPool to Locked?
Back to singing my same old song:
You DO realize that much of this goofy hacking the kernel stuff is
actively
prevented on 64-bit Windows systems, right?
Peter
OSR
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Peter,
I’m being dense today, What mechanism are you referring to? I know
of the NX bit, and similar but I don’t know of something that checks against
mapping the kernel to read/write through an MDL then changing the code.
Inquiring minds want to know. I would never use this hack in a product, but
I have used it for private diagnostics.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Peter Viscarola (OSR)” wrote in message
news:xxxxx@ntdev…
> Back to singing my same old song:
>
> You DO realize that much of this goofy hacking the kernel stuff is
> actively prevented on 64-bit Windows systems, right?
>
> Peter
> OSR
>
>
Peter Viscarola (OSR) wrote:
Back to singing my same old song:
You DO realize that much of this goofy hacking the kernel stuff is actively
prevented on 64-bit Windows systems, right?
[Note: I’ve moved this to a new thread “Kernel Hooking vs. a sane solution”]
Jerry Schneider
> security is concerned. It bothers me immensely that Intel put
such an enormous amount of security-oriented functionality into
the i386 architecture, and, well, nobody uses any of it.
Where is this “enormous amount”? Lack of NoExecute bit in PTEs?
door. So, the way I think it should be is, trusted code in Ring
0, I/O in Ring 1 (no, dudes, I/O is *not* trusted code nor
should it be treated as such), Services in Ring 2 and
…and then forget any chances of portability.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Yes. Oddly enough, in many ways Win16 was a more secure environment
than Win32, because Win16 used segmentation extensively.
???
Any DLL’s data segment was shared between all processes. Any global memory
allocation - too.
No security at all in Win3.1 and its direct descendant Win9x/Me. Any app can
junk the data segment of the important DLL and crash the OS.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Four rings of protection. Procedure calls chanelled through one
of two tables, one system-owned, the other user-owned. Ability
of restrict access to procedures through the specification of
gates. Ability to run an ISR as a task - through a task gate.
Automatic stack switching on a privilege level switch so that
malicious code cannot violate encapsulation by peeking at
someone else’s stack. Type-checked Segmentation to differentiate
between code and data segments, so that one cannot run code out
of a data segment unless the OS’s weak enough to allow it.
Separate stack segment to prevent stacks overflowing into data
segments or vice versa. Limit-checked Segmentation to trap
buffer overflows as a protection violation, allowing the OS to
get control before the hacker does. Debug registers, so that
debuggers don’t need to hook. Ability to expand stack sizes on
the fly to avoid stack overflow crashes. Ability to implement a
clean message-passing microkernel architecture by encapsulating
messages and objects inside segments and passing segment
selectors instead. Machine instructions to perform pointer
validation. Hardware-implemented task switching to maintain
strict separation between tasks. I/O Privilege level to control
access to i/o space. I/O permission bit map to select i/o
privilege on a task basis. System Management Mode to isolate
power management and other sensitive code.
I could go on, there’s a lot more in that machine than flat
mode!
Alberto.
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 23, 2005 4:49 PM
Subject: Re: Re:[ntdev] Converting MDL from NonPagedPool to
Locked?
>> security is concerned. It bothers me immensely that Intel put
>> such an enormous amount of security-oriented functionality
>> into
>> the i386 architecture, and, well, nobody uses any of it.
>
> Where is this “enormous amount”? Lack of NoExecute bit in
> PTEs?
>
>> door. So, the way I think it should be is, trusted code in
>> Ring
>> 0, I/O in Ring 1 (no, dudes, I/O is not trusted code nor
>> should it be treated as such), Services in Ring 2 and
>
> …and then forget any chances of portability.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
Where there’s a will there’s a way. If everything fails,
virtualize: poor OS, still believes it’s running on the iron,
but what do you know ? It just ain’t so. The only real issue, as
I see it, is the good old ROI: these things take effort,
precision, care and time, and a whole lot of knowledge that must
span hardware and software. It’s like brain surgery, you use it
sparingly and only when there’s no other way to achieve the
result you want. But there’s a big difference between using it
judiciously and being forbidden from using it.
And you know what ? The day an OS prevents me from achieving the
results I need to achieve on my computers, it’s time to switch.
Alberto.
----- Original Message -----
From: “Peter Viscarola (OSR)”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 23, 2005 11:25 AM
Subject: Re:[ntdev] Converting MDL from NonPagedPool to Locked?
> Back to singing my same old song:
>
> You DO realize that much of this goofy hacking the kernel
> stuff is actively prevented on 64-bit Windows systems, right?
>
> Peter
> OSR
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
Actually, Microsoft themselves were guilty of that sin. When I
wrote Win3.1/Win9x display drivers for a living, one of the
favorite starting points was the IBM 8514 driver. Well, that
driver implemented the software BitBlt by taking the ROP and
compiling the core of the blitter on the fly, on the stack, and
then it used perfectly valid system calls to make a code segment
out of that memory area. That saved oodles of overhead when
doing a software blt, but heck, I can almost see Viscarola and
Burns going pale - or red - at the very mention of that hack. I
remember I once decided to get rid of it and to write all my 256
ROP inner loops in machine code, but that was a huge amount of
work and it took a while to weed out the bugs.
Alberto.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 23, 2005 12:02 PM
Subject: Re: [ntdev] Converting MDL from NonPagedPool to Locked?
> Alberto Moreira wrote:
>
>> Actually, if code and data didn’t share the same physical
>> memory, a great stride forward would have been taken as far
>> as security is concerned. It bothers me immensely that Intel
>> put such an enormous amount of security-oriented
>> functionality into the i386 architecture, and, well, nobody
>> uses any of it. Consider: if a buffer overflow is just that,
>> a buffer overflow, and it is impossible to realize a set of
>> instructions out of it because that’s not the code segment
>> nor is it aliased to a code segment, it can be pretty hard to
>> insert anything through a back door. So, the way I think it
>> should be is, trusted code in Ring 0, I/O in Ring 1 (no,
>> dudes, I/O is not trusted code nor should it be treated as
>> such), Services in Ring 2 and Applications in Ring 3. But no,
>> Risc is better, no ? Heck, one gets what one pays for.
>
>
> Yes. Oddly enough, in many ways Win16 was a more secure
> environment than Win32, because Win16 used segmentation
> extensively.
>
> Of course, Windows 3.x didn’t prevent an application from
> creating a new data selector aliased to the code segment, but
> that would have been pretty easy to fix.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com