[lug] SELinux

Mon Jan 29 16:57:51 MST 2018

You can do a lot of nasty things using AOP if you can get an arbitrary jar
onto the server. Remember your sysadmins and all it takes is one
sufficiently tempted by money, drugs, or sex to look the other way for a
moment.

Most of the vulnerabilities I know involve specially constructed bytecode
(java classes). They're akin to the ping of death - binary objects
carefully constructed so they pass basic validation but produce bad
objects. Servlets (client-side) were relatively easy to get to load classes
from untrustworthy sources but servers should be less trusting.

On Mon, Jan 29, 2018 at 4:49 PM, Steve Sullivan <steve.sullivan at mathcom.com>
wrote:

> Ok, I'll ask ... can you give any examples of server side
> vulnerabilities for Java?  I read a bit at
>
> https://dzone.com/articles/test-test-test-7
> and
> https://www.cvedetails.com/vulnerability-list/vendor_id-
> 93/product_id-19117/Oracle-JRE.html
>
> The list of 544 vulnerabilities at cvedetails looks intimidating,
> but reading down it looks like most of the problems are applet
> related.  Almost nobody uses applets anymore.
>
> And many of the entries say "require human interaction from a
> person other than the attacker".  Well, no fair -- if you have
> inside help, nearly anything is possible!
>
> Have you experienced any server side Java security issues?
>
> Steve
>
> On Mon, Jan 29, 2018 at 02:32:54PM -0700, Bear Giles wrote:
> > It's the same as debugging optimized C code. When you single-step through
> > the code the lines of code might not be executed sequentially but they're
> > never reordered in a way that breaks the logic. Remember that keyhole
> > optimizers work on a very limited set of patterns so they can be proven
> to
> > be correct.
> >
> > On Mon, Jan 29, 2018 at 2:01 PM, <mad.scientist.at.large at tutanota.com>
> > wrote:
> >
> > > so how can anyone debug or audit code if the JIT compiler keeps
> optimizing
> > > it repeatedly, cosnstantly changing the machine language code.  you'd
> have
> > > to debug the jit compiler and your' code at the same time. again i
> think
> > > this is terrible design for reliability and security as there is no
> way to
> > > audit the actual machine code.  this constant optimizing sounds like an
> > > excellent way to introduce unpredictable (or nearly so) bugs and
> frustrate
> > > any attempt to solve hard bugs or even guess where the bugs are in the
> code.
> > >
> > > I do realize java has had a lot more development time spent on it than
> > > pascal.
> > >
> > > mad.scientist.at.large (a good madscientist)
> > > --
> > > God bless the rich, the greedy and the corrupt politicians they have
> put
> > > into office.   God bless them for helping me do the right thing by
> giving
> > > the rich my little pile of cash.  After all, the rich know what to do
> with
> > > money.
> > >
> > >
> > > 29. Jan 2018 13:54 by bgiles at coyotesong.com:
> > >
> > >
> > > It's really unfair to compare the JVM to the pascal p-machine.
> There's a
> > > superficial similarity but it's had 20 years of optimizations by smart
> > > people with strong motivations. Hence things like the JIT
> (just-in-time)
> > > optimizer. The JVM is machine-independent but the JIT is a
> > > platform-specific keyhole optimizer that can replace blocks of bytecode
> > > with optimized native code. It gets more aggressive about unrolling
> loops,
> > > inlining method, etc., as the block of code is repeatedly called. A
> > > long-running server may be mostly optimized native code.
> > >
> > > On Mon, Jan 29, 2018 at 1:38 PM, <mad.scientist.at.large at tutanota.com>
> > > wrote:
> > >
> > >> sorry, haven't used the various flavors of java.  If it's compiled,
> then
> > >> such flaws are a compiler problem or a problem with the java engine.
> I
> > >> assume the JVM bytecode is run on an interpreter, similar to the way
> pascal
> > >> produces code for a hypothetical machine, though some pascal compiler
> do
> > >> provide target code.
> > >>
> > >> good info, i thank all.  definately worth the hassle if properly
> > >> configured and one stays away from dodgey/poorly written compilers and
> > >> interpreters.  I'm well aware that all code of any size/complexity
> will
> > >> have bugs, plus bugs from compilers/interpreters.  heap and stack
> overflow
> > >> exploits continue to be common, as well as other security holes.
>  trading
> > >> proper data/instructions isolation in memory is a very poor practice
> and
> > >> terrible way to get speed.  I know well firefox's myriad problems.
> > >>
> > >>
> > >>
> > >> mad.scientist.at.large (a good madscientist)
> > >> --
> > >> God bless the rich, the greedy and the corrupt politicians they have
> put
> > >> into office.   God bless them for helping me do the right thing by
> giving
> > >> the rich my little pile of cash.  After all, the rich know what to do
> with
> > >> money.
> > >>
> > >>
> > >> 29. Jan 2018 13:20 by bgiles at coyotesong.com:
> > >>
> > >>
> > >> ? Java isn't interpreted. It compiles to JVM bytecode but the JIT
> > >> optimizer is now good enough that it can outperform C on long-running
> code.
> > >>
> > >> It's worth noting that Java's myriad security weaknesses (after the
> first
> > >> few years when poor decisions were shaken out) reflect the fact that
> it's
> > >> such a high value target that attackers will look at obscure corner
> cases.
> > >> It's not proof that it's inherently less secure than other platforms
> > >> (*cough* C libraries) and it has a lot of features that would make
> systems
> > >> much more secure if people used them. You can certainly design more
> secure
> > >> virtual machines but you'll lose functionality, at least at the
> moment.
> > >>
> > >> On Sun, Jan 28, 2018 at 10:04 PM, <mad.scientist.at.large@
> tutanota.com>
> > >> wrote:
> > >>
> > >>> that's just one more reason not to write things in java.  if i were
> > >>> "enterprise" i'd probably be doing the writing in a real language,
> for most
> > >>> things i hate interpreted languages, they are slow, slow, slow if
> doing any
> > >>> real work.  But i do see you're point, considering how "HOT" java
> is.  I
> > >>> mean the whole point is security, using java is hardly helpful in
> that
> > >>> pursuit, but i know you have to give the customer what they want.
> > >>>
> > >>> Yes, i will learn it as it's another usefull layer for security in
> > >>> depth.  I also plan to run multiple, different firewalls (banking
> industry
> > >>> standard, for web access is 3 layers of fire wall from different
> vendors,
> > >>> last i heard anyway).
> > >>>
> > >>> mad.scientist.at.large (a good madscientist)
> > >>> --
> > >>> God bless the rich, the greedy and the corrupt politicians they have
> put
> > >>> into office.   God bless them for helping me do the right thing by
> giving
> > >>> the rich my little pile of cash.  After all, the rich know what to
> do with
> > >>> money.
> > >>>
> > >>>
> > >>> 28. Jan 2018 21:16 by zlynx at acm.org:
> > >>>
> > >>>
> > >>> On 1/28/2018 4:11 PM, mad.scientist.at.large at tutanota.com wrote:
> > >>>
> > >>> the defaults in centos 6.9 (run by RH) enables many dangerous
> options by
> > >>> default, like executing code in the heap or memory shared with
> variables
> > >>> and program,
> > >>>
> > >>>
> > >>> You cannot run Java applications without those things. Just try being
> > >>> "enterprise" without Java.
> > >>> _______________________________________________
> > >>> Web Page: http://lug.boulder.co.us
> > >>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > >>> Join us on IRC: irc.hackingsociety.org port=6667
> channel=#hackingsociety
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Web Page:  http://lug.boulder.co.us
> > >>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > >>> Join us on IRC: irc.hackingsociety.org port=6667
> channel=#hackingsociety
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> Web Page:  http://lug.boulder.co.us
> > >> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > >> Join us on IRC: irc.hackingsociety.org port=6667
> channel=#hackingsociety
> > >>
> > >
> > >
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > Join us on IRC: irc.hackingsociety.org port=6667
> channel=#hackingsociety
> > >
>
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
> --
>
> ========================================
> Steve Sullivan      steve.sullivan at mathcom.com
> 720-587-7498        http://www.mathcom.com
> ========================================
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20180129/9b320b00/attachment-0001.html>