[lug] SELinux

Mon Jan 29 17:07:27 MST 2018

That is to say - it's usually not a vulnerability despite clean code
(although we certainly have plenty of vulnerabilities due to poor coding
practices - any sufficiently complex language will). It's a vulnerability
from getting the system to load a carefully constructed object designed to
break the system. C is just as vulnerable if someone manages to get a
carefully constructed shared library into the ld path.

It's annoying since the JVM was designed to be secure. But that's also a
saving grace since you can fix the JIT and make the vulnerability disappear
- it just needs to beef up bytecode validation so it throws the appropriate
Error if the class has this malformed data. It's a lot harder to fix a
compromised shared library.

It's also worth noting that you can create "signed" jars that have a
cryptographic hash of each class in the jar. The class isn't loaded if the
hash doesn't match. I don't think it's widely done but you could sign all
of the jars you use and greatly reduce the opportunity for a bad guy to
sneak in untrusted code.

On Mon, Jan 29, 2018 at 4:57 PM, Bear Giles <bgiles at coyotesong.com> wrote:

> 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 at tutano
>> ta.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/ebe4e7ee/attachment.html>