mprotect W^X violation and JDK

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

mprotect W^X violation and JDK

currellberry
Every time I start or stop a java program, I see something similar to
the following logged in /var/log/messages

    Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation

My /usr/local partition is mounted with wxallowed.  Are these
warnings/errors expected?  My limited understanding of the wxallowed
flag was that it mean that programs were allowed to commit W^X
violations.

Below are some details about the environment I am running java in.
It is openbsd 6.0 running inside virtualbox on a windows pc.

>Environment:
        System      : OpenBSD 6.0
        Details     : OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
                         [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC

        Architecture: OpenBSD.amd64
        Machine     : amd64

>How-To-Repeat:
        do fresh openbsd install
        verify that your /usr/local lies within a wxallowed partition
        set your PKG_PATH
        run pkg_add jdk (select jdk 8 from the menu)
        add /usr/local/jdk-1.8.0 to your path

        create a "hello world" java program(see example below).

        public class Test {
                public static void main(String[] args) {
                        System.out.println("hello world");
                }
        }

        run javac Test.java

        in one terminal window, tail -100f /var/log/messages

        in another run java Test

        observe the W^X violation being logged

>Fix:
        programs seem like they work properly, however I wanted to check whether this logging is the expected behavior or no as it is a bit worrysome.

dmesg:
OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056899072 (1007MB)
avail mem = 1020502016 (973MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 2793.85 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 999MHz
cpu0: mwait min=64, max=64
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "1" serial 0 type VBOX oem "innotek"
acpiac0 at acpi0: AC unit offline
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: <VBOX HARDDISK>
wd0: 128-sector PIO, LBA, 16384MB, 33554432 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <VBOX, CD-ROM, 1.0> ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 08:00:27:55:21:4c
"InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not configured
auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 1 int 21, ICH AC97
ac97: codec id 0x83847600 (SigmaTel STAC9700)
audio0 at auich0
ohci0 at pci0 dev 6 function 0 "Apple Intrepid USB" rev 0x00: apic 1 int 22, version 1.0
piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: apic 1 int 23
iic0 at piixpm0
em1 at pci0 dev 8 function 0 "Intel 82540EM" rev 0x02: apic 1 int 16, address 08:00:27:63:6d:5f
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Apple OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (24555dc8f83a2ce7.a) swap on wd0b dump on wd0b

usbdevs:
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), Apple(0x106b), rev 1.00
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 powered
 port 8 powered
 port 9 powered
 port 10 powered
 port 11 powered
 port 12 powered


-- Currell Berry

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Alex McWhirter
Java doesn't work with write xor execute and this is the kernels way of
letting you know. Java still runs because the partition is mounted with
wxallowed, but the kernel still prints the error to let you know that
Java isn't respecting a security feature.

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Stuart Henderson
In reply to this post by currellberry
On 2017-01-28, Currell Berry <[hidden email]> wrote:
> Every time I start or stop a java program, I see something similar to
> the following logged in /var/log/messages
>
>     Jan 28 02:15:46 wtestvm3 /bsd: java(37284): mprotect W^X violation
>
> My /usr/local partition is mounted with wxallowed.  Are these
> warnings/errors expected?  My limited understanding of the wxallowed
> flag was that it mean that programs were allowed to commit W^X
> violations.

Expected in 6.0, it will go away in 6.1/-current.

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

currellberry
In reply to this post by Alex McWhirter
Ok, thank you.  That resolves my concern that something was broken.

Alex McWhirter writes:

> Java doesn't work with write xor execute and this is the kernels way
> of letting you know. Java still runs because the partition is mounted
> with wxallowed, but the kernel still prints the error to let you know
> that Java isn't respecting a security feature.

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Christian Schulte
In reply to this post by Alex McWhirter
Am 01/28/17 um 10:04 schrieb Alex McWhirter:
> Java doesn't work with write xor execute and this is the kernels way of
> letting you know. Java still runs because the partition is mounted with
> wxallowed, but the kernel still prints the error to let you know that
> Java isn't respecting a security feature.
>

What should the VM do instead? It allocates memory, JIT compiles
bytecode to machinecode and then executes that machinecode. Should it
mprotect the memory after generating the machinecode? It would still
execute code from memory it could write to.

Regards,
--
Christian

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Alex McWhirter
In reply to this post by currellberry
On Jan 28, 2017 2:02 PM, Christian Schulte <[hidden email]> wrote:

  Am 01/28/17 um 10:04 schrieb Alex McWhirter:
  > Java doesn't work with write xor execute and this is the kernels
  way of
  > letting you know. Java still runs because the partition is mounted
  with
  > wxallowed, but the kernel still prints the error to let you know
  that
  > Java isn't respecting a security feature.
  >

  What should the VM do instead? It allocates memory, JIT compiles
  bytecode to machinecode and then executes that machinecode. Should it
  mprotect the memory after generating the machinecode? It would still
  execute code from memory it could write to.

  Regards,
  --
  Christian

Java's memory strategy would have to change. IIRC, java basically
allocates one big chunk of memory and the JVM uses it as a single heap.
The most simple way I can think of would be to enable w^x support in the
java language itself and allow each java application to define whether or
not they use it and how they use it.
Another is to make the JVM smart enough to know what needs write and what
needs execute, but not both.
But that's up to Oracle im afraid, and im not certain of how much they
really care. Most likely it will be done when every other OS on the
planet starts enforcing w^x and Oracle kinda has to do it.

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Stuart Henderson
In reply to this post by Christian Schulte
On 2017-01-28, Christian Schulte <[hidden email]> wrote:

> Am 01/28/17 um 10:04 schrieb Alex McWhirter:
>> Java doesn't work with write xor execute and this is the kernels way of
>> letting you know. Java still runs because the partition is mounted with
>> wxallowed, but the kernel still prints the error to let you know that
>> Java isn't respecting a security feature.
>>
>
> What should the VM do instead? It allocates memory, JIT compiles
> bytecode to machinecode and then executes that machinecode. Should it
> mprotect the memory after generating the machinecode? It would still
> execute code from memory it could write to.

Yes, but that still helps because it can't execute and write the same
address space at the same time.

http://blog.acumensecurity.net/fpt_wx_ext-1-a-rundown/#comment-11564
may be of interest.

Reply | Threaded
Open this post in threaded view
|

Re: mprotect W^X violation and JDK

Theo de Raadt-2
In reply to this post by Alex McWhirter
> Java doesn't work with write xor execute and this is the kernels way of
> letting you know. Java still runs because the partition is mounted with
> wxallowed, but the kernel still prints the error to let you know that
> Java isn't respecting a security feature.

If people aren't made aware repeatedly of an outstanding unrepaired
issue, how will they ever come around to trying to fix it?

A number of programs with W^X issues are very hard to fix.  First off,
the programs are very large, or the problem is inside a set of
libraries which have great complexity or deep interaction.  Especially
when threads are involved.

But the problems still need to be solved.  Such programs should strive
to toggle memory between writeable and executable, to reduce the methods
an attacker would use succesfully.  This doesn't solve security problems
outright, but it increases the complexity of attack.

Back to the main point: If people don't know there is an issue, why
will they ever strive to fix it