Those in search of ways to accomplish this, without modification to the
hypervisor itself can be interested on one of two things :
#1 - getting credit at secunia (and divulging a method that could bring
hosts to their knees) *or*
#2 - black mailing a xen host such as unixshell or others.
No other useful scenario is possible. Either outcome of either scenario
is ugly given the adaptation of Xen by public hosting providers who
offer root access to a guest OS for $15 and don't verify the buyer. Even
if they did, $15 gets you 'root' and the ability to cause serious
disruptions (and the host quite a bit of money), enough to pay someone
to stop.
While I appreciate the academic nature of this list, please do not 'play
into' social engineering, especially if you've been able to accomplish
bad things in the lab.
This is a fishing expedition, there is no other possible explanation.
Best,
--Tim
On Wed, 2007-01-10 at 14:41 +0100, Petersson, Mats wrote:
> > -----Original Message-----
> > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > Security Initiative Team
> > Sent: 10 January 2007 01:42
> > To: Petersson, Mats; Diwaker Gupta
> > Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xen-users] Tracking DomU memory
> >
> > Is it possible for the "root" user of a guest domain to
> > update the "text" section of a user-level process in that
> > guest domain?
>
> Sure can do - but what purpose would that serve - there is even an API
> to do this, called the "ptrace" functions in the kernel. It's intended
> for debuggers and the like, but can be used for other purposes if you
> wish to.
>
> >
> > The text section is mapped as read-only,
> > but is the "root" user privileged enough to be able to
> > update the page-table entry (which will go through Xen)
> > to make it a writable mapping and then update it?
>
> Sure, you could do that - but there are non-trivial things to consider.
>
> You'll probably be better off trying to do this by modifying the code in
> the hypervisor, but even that is definitely non-trivial.
>
> As mentioned elsewhere, consider two processors accessing the same page
> simultaneously, just as one example of "things that are difficult to
> handle".
>
> I'm a bit surprised about the interest in "tracing/tracking writes to
> memory" cropping up again and again on this mailing list. I know why I'm
> working on such thing (checking specific writes to specific
> memory-mapped IO areas), but I'm concerned about the belief that a
> general option for tracing/tracking memory writes to generic memory
> would be particularly useful and even achievable - bearing in mind that
> under normal circumstances the processor may perform multiple writes per
> clock-cycle in any number of different regions (stack, data section and
> "bss" section, shared memory sections, etc, etc) - a single page-fault
> will take several dozen clock-cycles just to get to the page-fault
> handler and out of it again, followed by many dozens of cycles needed to
> sort out what caused the page-fault and "fixing it up", so we're talking
> about something that would potentially slow the processor down by a
> factor of around 100. If you are prepared to take that sort of
> slow-down, then I'd suggest a simulator that has memory tracing/tracking
> capabilities - as it's probably going to be 2-5x faster than the "trap
> and fix" way to solve the problem.
>
> --
> Mats
> >
> >
> >
> > "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:
> >
> > > -----Original Message-----
> > > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > > Diwaker Gupta
> > > Sent: 15 December 2006 22:56
> > > To: Security Initiative Team
> > > Cc: Petersson, Mats; xen-users@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-users] Tracking DomU memory
> > >
> > > I actually want do to something similar, but simpler. I'm only
> > > interested in keeping track of pages that a guest
> > domain is accessing
> > > (both reads and writes). I'm _not_ looking for the
> > *exact* memory
> > > address -- just the physical page being accessed. Can
> > log dirty be
> > > modified to keep track of read accesses as well?
> >
> > This isn't far from what I'm doing (except I need to
> > look at one or a
> > few pages, which makes life somewhat easier).
> >
> > You'd have to change the page-table writes so that they
> > are written with
> > "not present", and then update your statistics based on
> > the page-fault.
> > You'll have to "fix" the fault and then reset the
> > page-table, which is
> > probably easiest done by using the x86_emulate_memop() function
> > [alternatively, set the trace-bit in the flags on stack
> > before exiting
> > the PF-handler, take the trace-interrupt, reset the
> > page-table and
> > continue].
> >
> > However, if you're doing this for every memory access
> > of the guest,
> > you'll not get much work done... :-(
> >
> > --
> > mats
> > >
> > > Thanks,
> > > Diwaker
> > >
> > > On 10/9/06, Security Initiative Team wrote:
> > > > My main purpose is to know when a user-level
> > application in DomU
> > > > is updating its memory.
> > > > (Tracking changes to the stack segment might be too hard
> > > due to frequent
> > > > memory updates, so maybe only the "text" segment).
> > > >
> > > > I want to be able to track this from either Dom0 or the
> > > hypervisor layer,
> > > > whichever is easier.
> > > >
> > > > When is ptwr_emulated_update() used and when is
> > do_mmu_update()
> > > > used?
> > > >
> > > > Thanks,
> > > > -Criag
> > > >
> > > >
> > > > "Petersson, Mats" wrote:
> > > >
> > > > What do you ACTUALLY want to do?
> > > >
> > > > log-dirty doesn't log to a file - it keeps track of "dirty"
> > > pages in a list
> > > > in memory, but doesn't actually store it in a file
> > [ever, at all].
> > > >
> > > > do_mmu_update is possibly a good place to hook into, but it
> > > depends on what
> > > > you want to do... [And it's non-trivial code, so beware of
> > > complications
> > > > from changing it].
> > > >
> > > > You may want to look at ptwr_emulated_update, as that's
> > > used when the
> > > > do_mmu_update() hypercall isn't used to update a
> > page-table-entry.
> > > >
> > > > --
> > > > Mats
> > > >
> > > >
> > > > ________________________________
> > > --
> > > Web/Blog/Gallery: http://floatingsun.net/blog
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-users
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home