Re: [Fed-Talk] OS X < 10.10 a "Critical" finding in ACAS
Re: [Fed-Talk] OS X < 10.10 a "Critical" finding in ACAS
- Subject: Re: [Fed-Talk] OS X < 10.10 a "Critical" finding in ACAS
- From: "Benjamin, Charles (NIH/CIT) [E]" <email@hidden>
- Date: Thu, 23 Oct 2014 15:19:21 +0000
- Thread-topic: [Fed-Talk] OS X < 10.10 a "Critical" finding in ACAS
It has been frustrating at times working with Apple in the enterprise for the reasons you stated. As a general rule with most every other OS you are not "forced" to advance on THAT manufacturers (Apple in this case) schedule without any kind of real window. I am most frustrated with the marrying of the hardware to the OS by force in the case of Apple. What I mean by that is that it seems based on the specs that the older version of the of the OS (1 rev behind) should run just fine on the "new model" because it is not really new. However the firmware is setup to specially prevent an earlier rev from running. What on earth? I do need to wait for all of the other manufacturers of software to catch up to the new rev and meanwhile I still need to replace existing machines. Absolutely nuts. I understand trying to provide consistent quality levels but would it really break them to support current and former rev consistently? Deprecating the OS as it stand now should have a larger window in my opinion. I would like to see a one year window to allow everyone (other manufacturers) else to catch up.
That being said, this is ultimately the choice of the user. They can switch platforms. Yes there is a fair amount of legacy software and etc out there that I am sure needs to be rewritten to work on another platform but it is an option. If the original manufacturer is defunct and code not released for public consumption it can be replaced even if it means internal development. It’s a problem of people not planning or allocating resources. If something is that important resources should be allocated. Often times I have to wonder if the problem would be solved if workflow/business process/whatever you wish to call it insisted this was pointed out and evaluated year to year as opposed to "Its broke you have to fix it now." Make it a documented conscious effort to ignore the forthcoming problem. In our line of work I am often frustrated by customers/users that insist they should just be able to continue to work as it is when the world changes around them. We can provide solutions/options but at some point change needs to occur and the users/customers holding the purse strings do not want to budge.
Chuck Benjamin
Desktop Engineering
NIH/CIT
-----Original Message-----
From: fed-talk-bounces+benjamic=email@hidden [mailto:fed-talk-bounces+benjamic=email@hidden] On Behalf Of John Oliver
Sent: Thursday, October 23, 2014 10:54 AM
To: Apple Fed-Talk
Subject: Re: [Fed-Talk] OS X < 10.10 a "Critical" finding in ACAS
I don’t have to be a beta-tester for any other OS. I *could* be if I wanted to, but it isn’t a requirement. Windows, UNIX, Linux… every other OS in the world will let me keep using a GA release while evaluating the next major version release. All of them. And I can skip a GA if I want… Nobody HAD to go to Windows Vista, they could stick with XP until 7 had been out for a while. Nobody HAD to start using CentOS 6… they could stay on 5 (and still can, 5 is still supported, and will be for another three years, even as 6 and 7 are available and supported!)
You cannot do deployment testing on release candidates. If you aren’t using a final product, you’re wasting at least some of your time. Sure, it’s better than nothing, but you are not getting reliable results when changes are still being made.
And while I do agree with your point, that being that given the reality of how Apple does this, you have to accept the “this is as good as it gets”
answer, that STILL doesn’t give a valid answer to why the last release should be abandoned and unsupported instantly, and that a move to the new release should happen within a few weeks. At least we used to have the unofficial “n - 2” rule, and had some degree of confidence that a given release ought tbe supported for about two more years, maybe. Now even that’s gone. That is **NOT** good for anyone. They’re getting worse about this, not better.
On 10/23/14, 7:35 AM, "Levine, Jason (NIH/NCI) [E]"
<email@hidden> wrote:
>I generally agree that there’s a disconnect between the 10.10 release
>and any central expectations that 10.9 be taken off the network ASAP
>(and Apple’s expectation that the release of 10.10 means that their
>need to support 10.9 vanishes entirely)... but I also have to push back
>a little bit on one part of your response. Respectfully, if you
>administer more than a handful of OS X systems, then you really need to
>be a part of the OS X developer seed or beta process — it’s part and
>parcel of being a system administrator. And that means that you’ll be
>in a fairly good position at the point of a new OS X release to know
>whether it’ll be ready for your environment, what the blockers are, etc.
>
>(And to anticipate the response that sysadmins just don’t have time to
>participate: without a doubt, you’re going to have to do this testing
>at some point. Right now, most do the testing after release, meaning
>that it’s rushed, it’s suboptimal, and it’s generally fraught with
>frustration on the part of both users and sysadmins. Moving it back
>into the developer seed/beta cycle means that you can do it in a more
>controlled fashion, and more importantly, as you identify blockers that
>are based on third-party dependencies, you can work with those parties
>to resolve them before the general OS release.)
>
>Jason
>
>
>Jason Levine, email@hidden<mailto:email@hidden>
>NCI CCR Acting Associate Director for IT and Clinical Informatics NCI
>CCR Pediatric Oncology Branch
>(240) 276-5557
>
>On Oct 23, 2014, at 10:26 AM, John Oliver
><email@hidden<mailto:email@hidden>> wrote:
>
>This has nothing to do with a government fixation on numbers, and
>everything to do with the fact that it’s an incredibly bad idea to
>shove out a new OS release to your users without being able to
>thoroughly test it. Yosemite is **NOT** “just an upgrade”, or it would
>be 10.9.6 and would not introduce any new or different features or functionality.
>
>
>Anyone who admins more than a handful of systems knows how critical it
>is to be able to reliably deliver a product that meets the needs of the
>mission. Apple seems to be actively fighting that concept. I
>understand their fixation on the “user experience”, but that simply
>cannot be the primary motivator in an enterprise. We have to expend a
>great deal of energy fighting Apple as it is, but if they are going to
>abandon each release because “Oh, look, shiny!”, they’re simply
>creating even more problems.
>
>I’m a little disappointed… I was hoping for input from those who face
>similar challenges instead of “If Apple does it, it must be right!”
>Because they aren’t here. Not by a long shot.
>
>Oh well.
>
>
>On 10/22/14, 4:45 PM, "Joel Esler"
><email@hidden<mailto:email@hidden>> wrote:
>
>Agreed.
>
>and I know that the Government has issues with version numbers
>changing, etc, but I feel like its 2014, and that’s something that the
>Government needs to figure out how to get past.
>
>
>On Oct 22, 2014, at 4:18 PM, William Cerniuk
><email@hidden<mailto:email@hidden>> wrote:
>
>I would not say that we should not expect updates because Yosemite is
>free. Free has nothing to do with it. The release of Yosemite
>deprecates Mavericks. Apple is a hardware company and they do not act
>like Microsoft who is a software company and makes their core profits
>from selling versions and support of old stuff.
>
>Think of it this way, does anyone expect Windows CE to be patched? How
>about Windows NT? Why not? Because they are deprecated?
>
>Look at how hard it is for Microsoft to sustain all of their old
>versions of software and how much it costs enterprises to remain in the
>old legacy versions. Why I know of large institutions running MS
>Exchange 2003 which has been deprecated for years. ;-)
>
>And look at how fast Apple comes out with new versions… A very
>different approach.
>
>Think of Yosemite as the update to Mavericks to address the issues.
>
>But the biggest possible threat to the network still remains the
>company that issues bushels of patches every Tuesday.
>
>--
>R/Wm.
>
>Ph: 703.594.7616
>AppleID: email@hidden<mailto:email@hidden>
><mailto:email@hidden>
>
>
>
>
>
>On 22-Oct-2014, at 19:00, John Oliver
><email@hidden<mailto:email@hidden>
><mailto:email@hidden>> wrote:
>
>Has anyone else run into this?
>
>The day Yosemite was released, we were told that Mavericks was the
>biggest threat possible on the network. I pushed back, hard. They
>sent a list of CVEs they claim are not fixed in Mavericks and won’t be
>since Yosemite is “free”
>
>Right now, I really don’t know which is more or less likely…
>overzealous network security, lazy ACAS/Nessus plugin authors, or Apple
>abandoning an OS because they don’t see any reason why everyone
>shouldn’t upgrade the instant a new release is available, no testing
>necessary!
>
>Here’s the list of CVEs that was sent to me:
>
>CVE-2014-4364 : Pieter Robyns, Bram Bonne, Peter Quax, and Wim Lamotte
>of Universiteit Hasselt
>Impact: An attacker can obtain WiFi credentials Apple mentions patching
>CVE-2014-4364 in its Release notes. Neither Miter nor NIST have
>mentioned this in OSX yet. However they have not updated this CVE since
>last month and Yosemite was just released on 10/16/2014.
>National Cyber Awareness System
>
>CVE-2014-4364
>Original release date: 09/18/2014
>Last revised: 09/18/2014
>Source: US-CERT/NIST
>Overview
>The 802.1X subsystem in Apple iOS before 8 and Apple TV before 7 does
>not require strong authentication methods, which allows remote
>attackers to calculate credentials by offering LEAP authentication from
>a crafted Wi-Fi AP and then performing a cryptographic attack against
>the MS-CHAPv1 hash.
>Impact
>CVSS Severity (version 2.0):
>CVSS v2 Base Score: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:P/I:N/A:N) (legend)
>Impact Subscore: 2.9 Exploitability Subscore: 8.6 CVSS Version 2
>Metrics:
>Access Vector: Network exploitable; Victim must voluntarily interact
>with attack mechanism Access Complexity: Medium
>Authentication: Not required to exploit Impact Type: Allows
>unauthorized disclosure of information
>
>CVE-2014-4426 : Craig Young of Tripwire VERT
>Impact: A remote attacker could determine all the network addresses of
>the system Vulnerability Summary for CVE-2014-4426 Original release
>date: 10/17/2014 Last revised: 10/17/2014
>Source: US-CERT/NIST
>This vulnerability is currently undergoing analysis and not all
>information is available.
>AFP File Server in Apple OS X before 10.10 allows remote attackers to
>discover the network addresses of all interfaces via an unspecified
>command to one interface.
>apache
>Impact: Multiple vulnerabilities in Apache
>Description: Multiple vulnerabilities existed in Apache, the most
>serious of which may lead to a denial of service. These issues were
>addressed by updating Apache to version 2.4.9.
>
>CVE-2013-6438
>Source: US-CERT/NIST
>Overview
>The dav_xml_get_cdata function in main/util.c in the mod_dav module in
>the Apache HTTP Server before 2.4.8 does not properly remove whitespace
>characters from CDATA sections, which allows remote attackers to cause
>a denial of service (daemon crash) via a crafted DAV WRITE request.
>Impact
>CVSS Severity (version 2.0):
>CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/Au:N/C:N/I:N/A:P) (legend)
>Impact Subscore: 2.9 Exploitability Subscore: 10.0 CVSS Version 2
>Metrics:
>Access Vector: Network exploitable
>Access Complexity: Low
>Authentication: Not required to exploit Impact Type: Allows disruption
>of service
>
>CVE-2014-0098
>Overview
>The log_cookie function in mod_log_config.c in the mod_log_config
>module in the Apache HTTP Server before 2.4.8 allows remote attackers
>to cause a denial of service (segmentation fault and daemon crash) via
>a crafted cookie that is not properly handled during truncation.
>Impact
>CVSS Severity (version 2.0):
>CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/Au:N/C:N/I:N/A:P) (legend)
>Impact Subscore: 2.9 Exploitability Subscore: 10.0 CVSS Version 2
>Metrics:
>Access Vector: Network exploitable
>Access Complexity: Low
>Authentication: Not required to exploit Impact Type: Allows disruption
>of service
>
>CVE-2014-4427 : Paul S. Ziegler of Reflare UG This vulnerability is
>currently undergoing analysis and not all information is available.
>Impact: An application confined by sandbox restrictions may misuse the
>accessibility API
>Description: A sandboxed application could misuse the accessibility API
>without the user's knowledge. This has been addressed by requiring
>administrator approval to use the accessibility API on an
>per-application basis.
>
>CVE-2014-6271 : Stephane Chazelas
>CVE-2014-7169 : Tavis Ormandy
>Impact: In certain configurations, a remote attacker may be able to
>execute arbitrary shell commands
>Description: An issue existed in Bash's parsing of environment
>variables. This issue was addressed through improved environment
>variable parsing by better detecting the end of the function statement.
>This update also incorporated the suggested CVE-2014-7169 change, which
>resets the parser state.
>In addition, this update added a new namespace for exported functions
>by creating a function decorator to prevent unintended header
>passthrough to Bash. The names of all environment variables that
>introduce function definitions are required to have a prefix
>"__BASH_FUNC<" and suffix ">()" to prevent unintended function passing
>via HTTP headers.
>
>CVE-2014-4428 : Mike Ryan of iSEC Partners
>Impact: A malicious Bluetooth input device may bypass pairing
>Description: Unencrypted connections were permitted from Human
>Interface Device-class Bluetooth Low Energy devices. If a Mac had
>paired with such a device, an attacker could spoof the legitimate
>device to establish a connection. The issue was addressed by denying
>unencrypted HID connections.
>
>CVE-2014-4425
>Impact: The 'require password after sleep or screen saver begins'
>preference may not be respected until after a reboot
>Description: A session management issue existed in the handling of
>system preference settings. This issue was addressed through improved
>session tracking.
>
>CVE-2014-4430 : Benjamin King at See Ben Click Computer Services LLC,
>Karsten Iwen, Dustin Li (http://dustin.li/ <http://dustin.li/>), Ken J.
>Takekoshi, and other anonymous researchers
>Impact: An encrypted volume may stay unlocked when ejected
>Description: When an encrypted volume was logically ejected while
>mounted, the volume was unmounted but the keys were retained, so it
>could have been mounted again without the password. This issue was
>addressed by erasing the keys on eject.
>
>CVE-2014-3537
>Impact: A local user can execute arbitrary code with system privileges
>Description: When the CUPS web interface served files, it would follow
>symlinks. A local user could create symlinks to arbitrary files and
>retrieve them through the web interface. This issue was addressed by
>disallowing symlinks to be served via the CUPS web interface.
>Description: A state management issue existed in the handling of the
>screen lock. This issue was addressed through improved state tracking.
>
>CVE-2014-4431 : Emil Sjölander of Umeå University
>Impact: In some circumstances, windows may be visible even when the
>screen is locked
>Description: A state management issue existed in the handling of the
>screen lock. This issue was addressed through improved state tracking.
>
>CVE-2014-4432
>Impact: The fdesetup command may provide misleading status for the
>state of encryption on disk
>Description: After updating settings, but before rebooting, the
>fdesetup command provided misleading status. This issue was addressed
>through improved status reporting.
>
>CVE-2014-4435 : knoy
>Impact: iCloud Lost mode PIN may be bruteforced
>Description: A state persistence issue in rate limiting allowed brute
>force attacks on iCloud Lost mode PIN. This issue was addressed through
>improved state persistence across reboots.
>
>CVE-2014-4373 : cunzhang from Adlab of Venustech
>Impact: An application may cause a denial of service
>Description: A NULL pointer dereference was present in the
>IntelAccelerator driver. The issue was addressed through improved error
>handling.
>
>CVE-2014-4405 : Ian Beer of Google Project Zero
>Impact: A malicious application may be able to execute arbitrary code
>with system privileges
>Description: A null pointer dereference existed in IOHIDFamily's
>handling of key-mapping properties. This issue was addressed through
>improved validation of IOHIDFamily key-mapping properties.
>
>CVE-2014-4404 : Ian Beer of Google Project Zero
>Impact: A malicious application may be able to execute arbitrary code
>with system privileges
>Description: A heap buffer overflow existed in IOHIDFamily's handling
>of key-mapping properties. This issue was addressed through improved
>bounds checking.
>
>CVE-2014-4436 : cunzhang from Adlab of Venustech
>Impact: An application may cause a denial of service
>Description: A out-of-bounds memory read was present in the IOHIDFamily
>driver. The issue was addressed through improved input validation.
>
>CVE-2014-4380 : cunzhang from Adlab of Venustech
>Impact: A user may be able to execute arbitrary code with system
>privileges
>Description: An out-of-bounds write issue exited in the IOHIDFamily
>driver. The issue was addressed through improved input validation.
>
>CVE-2014-4407 : @PanguTeam
>Impact: A malicious application may be able to read uninitialized data
>from kernel memory
>Description: An uninitialized memory access issue existed in the
>handling of IOKit functions. This issue was addressed through improved
>memory initialization.
>
>CVE-2014-4388 : @PanguTeam
>Impact: A malicious application may be able to execute arbitrary code
>with system privileges
>Description: A validation issue existed in the handling of certain
>metadata fields of IODataQueue objects. This issue was addressed
>through improved validation of metadata.
>
>CVE-2014-4418 : Ian Beer of Google Project Zero
>Impact: A malicious application may be able to execute arbitrary code
>with system privileges
>Description: A validation issue existed in the handling of certain
>metadata fields of IODataQueue objects. This issue was addressed
>through improved validation of metadata.
>
>CVE-2014-4371 : Fermin J. Serna of the Google Security Team
>CVE-2014-4419 : Fermin J. Serna of the Google Security Team
>CVE-2014-4420 : Fermin J. Serna of the Google Security Team
>CVE-2014-4421 : Fermin J. Serna of the Google Security Team
>Impact: A local user may be able to determine kernel memory layout
>Description: Multiple uninitialized memory issues existed in the
>network statistics interface, which led to the disclosure of kernel
>memory content. This issue was addressed through additional memory
>initialization.
>
>CVE-2014-4433 : Maksymilian Arciemowicz
>Impact: A maliciously crafted file system may cause unexpected system
>shutdown or arbitrary code execution
>Description: A heap-based buffer overflow issue existed in the handling
>of HFS resource forks. A maliciously crafted filesystem may cause an
>unexpected system shutdown or arbitrary code execution with kernel
>privileges. The issue was addressed through improved bounds checking.
>
>CVE-2014-4434 : Maksymilian Arciemowicz
>Impact: A malicious file system may cause unexpected system shutdown
>Description: A NULL dereference issue existed in the handling of HFS
>filenames. A maliciously crafted filesystem may cause an unexpected
>system shutdown. This issue was addressed by avoiding the NULL
>dereference.
>
>CVE-2014-4375 : an anonymous researcher
>Impact: A local user may be able to cause an unexpected system
>termination or arbitrary code execution in the kernel
>Description: A double free issue existed in the handling of Mach ports.
>This issue was addressed through improved validation of Mach ports.
>
>CVE-2011-2391 : Marc Heuse
>Impact: A person with a privileged network position may cause a denial
>of service
>Description: A race condition issue existed in the handling of IPv6
>packets. This issue was addressed through improved lock state checking
>
>CVE-2014-4408
>Impact: A local user may be able to cause an unexpected system
>termination or arbitrary code execution in the kernel
>Description: An out-of-bounds read issue existed in rt_setgate. This
>may lead to memory disclosure or memory corruption. This issue was
>addressed through improved bounds checking.
>
>CVE-2014-4442 : Darius Davis of VMware
>Impact: A local user can cause an unexpected system termination
>Description: A reachable panic existed in the handling of messages sent
>to system control sockets. This issue was addressed through additional
>validation of messages.
>
>CVE-2014-4422 : Tarjei Mandt of Azimuth Security
>Impact: Some kernel hardening measures may be bypassed
>Description: The random number generator used for kernel hardening
>measures early in the boot process was not cryptographically secure.
>Some of its output was inferable from user space, allowing bypass of
>the hardening measures. This issue was addressed by using a
>cryptographically secure algorithm.
>
>CVE-2014-4437 : Meder Kydyraliev of the Google Security Team
>Impact: A local application may bypass sandbox restrictions
>Description: The LaunchServices interface for setting content type
>handlers allowed sandboxed applications to specify handlers for
>existing content types. A compromised application could use this to
>bypass sandbox restrictions. The issue was addressed by restricting
>sandboxed applications from specifying content type handlers.
>
>CVE-2014-4438 : Harry Sintonen of nSense, Alessandro Lobina of Helvetia
>Insurances, Patryk Szlagowski of Funky Monkey Labs
>Impact: Sometimes the screen might not lock
>Description: A race condition existed in LoginWindow, which would
>sometimes prevent the screen from locking. The issue was addressed by
>changing the order of operations.
>
>CVE-2014-4439 : Patrick J Power of Melbourne, Australia
>Impact: Mail may send email to unintended recipients
>Description: A user interface inconsistency in Mail application
>resulted in email being sent to addresses that were removed from the
>list of recipients. The issue was addressed through improved user
>interface consistency checks.
>
>CVE-2014-4440 : Kevin Koster of Cloudpath Networks
>Impact: When mobile configuration profiles were uninstalled, their
>settings were not removed
>Description: Web proxy settings installed by a mobile configuration
>profile were not removed when the profile was uninstalled. This issue
>was addressed through improved handling of profile uninstallation.
>
>CVE-2014-4441 : Eduardo Bonsi of BEARTCOMMUNICATIONS
>Impact: File Sharing may enter a state in which it cannot be disabled
>Description: A state management issue existed in the File Sharing
>framework. This issue was addressed through improved state management.
>
>CVE-2014-4351 : Karl Smith of NCC Group
>Impact: Playing a maliciously crafted m4a file may lead to an
>unexpected application termination or arbitrary code execution
>Description: A buffer overflow existed in the handling of audio
>samples. This issue was addressed through improved bounds checking.
>
>CVE-2013-5150
>Impact: History of pages recently visited in an open tab may remain
>after clearing of history
>Description: Clearing Safari's history did not clear the back/forward
>history for open tabs. This issue was addressed by clearing the
>back/forward history.
>
>CVE-2014-4417 : Marek Isalski of Faelix Limited
>Impact: Opting in to push notifications from a maliciously crafted
>website may cause future Safari Push Notifications to be missed
>Description: An uncaught exception issue existed in
>SafariNotificationAgent's handling of Safari Push Notifications. This
>issue was addressed through improved handling of Safari Push
>Notifications.
>
>CVE-2014-3566 : Bodo Moeller, Thai Duong, and Krzysztof Kotowicz of
>Google Security Team
>Impact: An attacker may be able to decrypt data protected by SSL
>Description: There are known attacks on the confidentiality of SSL 3.0
>when a cipher suite uses a block cipher in CBC mode. An attacker could
>force the use of SSL 3.0, even when the server would support a better
>TLS version, by blocking TLS 1.0 and higher connection attempts. This
>issue was addressed by disabling CBC cipher suites when TLS connection
>attempts fail.
>
>CVE-2014-4443 : Coverity
>Impact: A remote attacker may be able to cause a denial of service
>Description: A null dereference existed in the handling of ASN.1 data.
>This issue was addressed through additional validation of ASN.1 data.
>
>CVE-2014-4444 : Gary Simon of Sandia National Laboratories, Ragnar
>Sundblad of KTH Royal Institute of Technology, Eugene Homyakov of
>Kaspersky Lab
>Impact: A local user might have access to another user's Kerberos
>tickets
>Description: A state management issue existed in SecurityAgent. While
>Fast User Switching, sometimes a Kerberos ticket for the switched-to
>user would be placed in the cache for the previous user. This issue was
>addressed through improved state management.
>
>--
>John Oliver | SAIC
>SPAWAR Systems Center Pacific | Code 53223 Sr. Systems Administrator
>Bldg 600 | Room 428N
>Office: (619) 553-9567
>Lab: (619) 553-6664
>email@hidden<mailto:email@hidden>
><mailto:email@hidden>
>email@hidden<mailto:email@hidden>
><mailto:email@hidden>
>DCO:
>email@hidden<mailto:email@hidden>
><mailto:email@hidden>_________________________________
>_
>_____________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list
>(email@hidden<mailto:email@hidden>
><mailto:email@hidden>)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden <mailto:email@hidden>
>
>_______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list
>(email@hidden<mailto:email@hidden>
><mailto:email@hidden>)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden <mailto:email@hidden>
>
>_______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list
>(email@hidden<mailto:email@hidden>)
>Help/Unsubscribe/Update your Subscription:
>v
>
>This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden